Re: Remove RMS from the GCC Steering Committee

[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://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Remove RMS from the GCC Steering Committee

[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://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Integer division on x86 -m32

[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://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Andrew Haley via Gcc-patches]

On 5/1/20 11:48 AM, JiangNing OS via Gcc-patches wrote:
> In reality, a lot of users are still using old gcc versions running on new 
> hardware. OpenJDK is a typical example, I think.

We can change the OpenJDK build scripts to use -moutline-atomics if
it's available. I agree with Richard that we should not change codegen
for an existing GCC release series unless there is a bug.

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

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

[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:
>>>
>>>   <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956418>
>>>
>>> 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://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Status of C++11 support

[Andrew Haley]

On 12/9/19 5:03 PM, Nicholas Krause wrote:
>> https://gcc.gnu.org/projects/cxx-status.html#cxx11
> I'm asking of what support exists in the gcc codebase itself not for other
> projects using gcc.

That is what you got.

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

Re: alloca (0) in include/libiberty.h

[Andrew Haley]

On 6/10/19 8:24 AM, Martin Liška wrote:

> I've just noticed that we have couple of alloca (0) in libiberty:
> 
> #ifndef REGEX_MALLOC
> # ifdef C_ALLOCA
>   alloca (0);
> # endif
> #endif
> 
> If I'm correct the value 0 has a special meaning that tells a C library
> to clean up all previous alloca allocations.
> 
> man alloca does not document the behavior

I'm sure it doesn't. This alloca(0) behaviour is a libiberty-internal
thing.

> Question is how legacy is alloca call from a standard library?

alloca(3) is implemented by GCC as a builtin. It's fast, simple, and
widely used. These days you might use variable-length arrays instead,
which are at least portable.

Is there some problem that you want to solve?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: aarch64 TLS optimizations?

[Andrew Haley]

On 5/17/19 2:51 PM, Tom Horsley wrote:
> I'm trying (for reason too complex to go into) to
> locate the TLS offset of the tcache_shutting_down
> variable from malloc in the ubuntu provided
> glibc on aarch64 ubuntu 18.04.
> 
> Various "normal" TLS variables appear to operate
> much like x86_64 with a GOT table entry where the
> TLS offset of the variable gets stashed.
> 
> But in the ubuntu glibc there is no GOT entry for
> that variable, and disassembly of the code shows
> that it seems to "just know" the offset to use.
> 
> Is there some kind of magic TLS optimization that
> can happen for certain variables on aarch64? I'm trying
> to understand how it could know the offset like
> it appears to do in the code.

https://www.fsfla.org/~lxoliva/writeups/TLS/paper-lk2006.pdf



-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Putting an all-zero variable into BSS

[Andrew Haley]

On 4/7/19 5:03 PM, Thomas Koenig wrote:
> Hi Richard,
> 
>> I don't know without looking, but I'd start at assemble_variable in varasm.c.
> 
> Thanks.  I've done that, and this is what a patch could look like.
> However, I will not have time to formally submit this until next
> weekend.
> 
> In the meantime, comments are still welcome :-)

Did you look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100

This was the change that caused this behaviour.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Andrew Haley]

On 3/22/19 10:20 AM, Allan Sandfeld Jensen wrote:
> On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote:
>> On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote:
>>> From having fixed UBSAN warnings, I have seen many cases where undefined
>>> behavior was performed, but where the code was aware of it and the final
>>> result of the expression was well defined nonetheless.
>>
>> Is this belief about undefined behaviour commonplace among C programmers?
>> There's nothing in the standard to justify it: any expression which contains
>> UB is undefined.
> 
> Yes, even GCC uses undefined behavior when it is considered defined for 
> specific architecture,

If it's defined for a specific architecture it's not undefined. Any compiler
is entitled to do anything with UB, and "anything" includes extending the
language to make it well defined.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Andrew Haley]

On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote:
> From having fixed UBSAN warnings, I have seen many cases where undefined 
> behavior was performed, but where the code was aware of it and the final 
> result of the expression was well defined nonetheless.

Is this belief about undefined behaviour commonplace among C programmers?
There's nothing in the standard to justify it: any expression which contains
UB is undefined.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Andrew Haley]

On 3/21/19 8:53 AM, Moritz Strübe wrote:
> Hey.
> 
> Am 20.03.2019 um 18:36 schrieb Andrew Haley:
>> On 3/20/19 2:08 PM, Moritz Strübe wrote:
>>> Ok, I played around a bit. Interestingly, if I set
>>> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
>>> compiler detects that it will always trap, and optimizes the code
>>> accordingly (the code after the trap is removed).* Which kind of
>>> brings me to David's argument: Shouldn't the compiler warn if there
>>> is undefined behavior it certainly knows of?
>> Maybe an example would help.
>>
>> Consider this code:
>>
>> for (int i = start; i < limit; i++) {
>>foo(i * 5);
>> }
>>
>> Should GCC be entitled to turn it into
>>
>> int limit_tmp = i * 5;
>> for (int i = start * 5; i < limit_tmp; i += 5) {
>>foo(i);
>> }
>>
>> If you answered "Yes, GCC should be allowed to do this", would you
>> want a warning? And how many such warnings might there be in a typical
>> program?
> 
> Ok, let me see whether I get your point. I assume that should be "int 
> limit_tmp = limit * 5;".

Yes, sorry.

> In the original version I have a potential integer overflow while 
> passing a parameter. While in the second version, I have a potential 
> overflow in limit_tmp and therefore the loop range and number of calls 
> of foo is changed.

That's right.

> I think I start getting your point, but I none the less think it would 
> be really nice to have an option(!) to warn me about such things 
> nonetheless.

There aren't necesarily points in the compiler where GCC says "look,
this would be UB, so delete the code." Sometimes GCC simply assumes
that things like overflows cannot happen, so it ignores the
possibility. The code I provided is an example of that.

I suppose we could utilize the sanitize=undefined framework and emit a
warning everywhere a runtime check was inserted. That will at least
allow you to check in every case that the overflow, null pointer
exception, etc, cannot happen.

There would be a lot of warnings.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Andrew Haley]

On 3/20/19 2:08 PM, Moritz Strübe wrote:
> 
> Ok, I played around a bit. Interestingly, if I set
> -fsanitize=udefined and -fsanitize-undefined-trap-on-error the
> compiler detects that it will always trap, and optimizes the code
> accordingly (the code after the trap is removed).* Which kind of
> brings me to David's argument: Shouldn't the compiler warn if there
> is undefined behavior it certainly knows of?

Maybe an example would help.

Consider this code:

for (int i = start; i < limit; i++) {
  foo(i * 5);
}

Should GCC be entitled to turn it into

int limit_tmp = i * 5;
for (int i = start * 5; i < limit_tmp; i += 5) {
  foo(i);
}

If you answered "Yes, GCC should be allowed to do this", would you
want a warning? And how many such warnings might there be in a typical
program?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: autovectorization in gcc

[Andrew Haley]

On 1/9/19 9:45 AM, Kyrill Tkachov wrote:
> Hi Kay,
> 
> On 09/01/19 08:29, Kay F. Jahnke wrote:
>> Hi there!
>>
>> I am developing software which tries to deliberately exploit the
>> compiler's autovectorization facilities by feeding data in
>> autovectorization-friendly loops. I'm currently using both g++ and
>> clang++ to see how well this approach works. Using simple arithmetic, I
>> often get good results. To widen the scope of my work, I was looking for
>> documentation on which constructs would be recognized by the
>> autovectorization stage, and found
>>
>> https://www.gnu.org/software/gcc/projects/tree-ssa/vectorization.html
>>
> 
> Yeah, that page hasn't been updated in ages AFAIK.
> 
>> By the looks of it, this document has not seen any changes for several
>> years. Has development on the autovectorization stage stopped, or is
>> there simply no documentation?
>>
> 
> There's plenty of work being done on auto-vectorisation in GCC.
> Auto-vectorisation is a performance optimisation and as such is not really
> a user-visible feature that absolutely requires user documentation.

I don't agree. Sometimes vectorization is critical. It would be nice
to have a warning which would fire if vectorization failed. That would
surely help the OP.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: movmem pattern and missed alignment

[Andrew Haley]

On 10/08/2018 07:38 PM, Paul Koning wrote:
> 
> 
>> On Oct 8, 2018, at 1:29 PM, Andrew Haley  wrote:
>>
>> On 10/08/2018 06:20 PM, Michael Matz wrote:
>>> Only if you somewhere visibly add accesses to *i and *j.  Without them you 
>>> only have the "accesses" via memcpy, and as Richi says, those don't imply 
>>> any alignment requirements.  The i and j pointers might validly be char* 
>>> pointers in disguise and hence be in fact only 1-aligned.  I.e. there's 
>>> nothing in your small example program from which GCC can infer that those 
>>> two global pointers are in fact 2-aligned.
>>
>> So all you'd actually have to say is
>>
>> void f1(void)
>> {
>>*i; *j;
>>__builtin_memcpy (i, j, 32);
>> }
> 
> No, that doesn't help. 

It could do.

> Not even if I make it:
> 
> void f1(void)
> {
> k = *i + *j;
> __builtin_memcpy (i, j, 4);
> }
> 
> The first line does word aligned references to *i and *j, but the memcpy 
> stubbornly remains a byte move.

Right, so that is a missed optimization.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: movmem pattern and missed alignment

[Andrew Haley]

On 10/08/2018 06:20 PM, Michael Matz wrote:
> Only if you somewhere visibly add accesses to *i and *j.  Without them you 
> only have the "accesses" via memcpy, and as Richi says, those don't imply 
> any alignment requirements.  The i and j pointers might validly be char* 
> pointers in disguise and hence be in fact only 1-aligned.  I.e. there's 
> nothing in your small example program from which GCC can infer that those 
> two global pointers are in fact 2-aligned.

So all you'd actually have to say is

void f1(void)
{
*i; *j;
__builtin_memcpy (i, j, 32);
}

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [llvm-dev] GCC 5 and -Wstrict-aliasing in JSON.h

[Andrew Haley]

On 08/10/2018 05:30 AM, Liu Hao wrote:
> Only an lvalue of a pointer to (possibly CV-qualified) `void` or a 
> pointer to a character type (in C) / any of `char`, `unsigned char` or 
> `std::byte` (in C++) can alias objects.

Yes.

> That is to say, in order to eliminate the aliasing problem an 
> intermediate lvalue pointer is required.

Not exactly.  You can cast a pointer to a pointer to some character
type or the type of the object stored in memory.  It does not matter
whether you use an intermediate type or not.  Having not seen the test
case, I can't tell whether this rule is followed.

What you can't do is store as a double, cast the double pointer to a
character pointer, cast that pointer to some other pointer type, and
read from memory.  GCC won't give you a warning for that, but it's
still undefined.

JSON.h seems to hope that if you cast a pointer to T to a pointer to
some union type, magic will happen.  It won't work, unless the object
stored in the memory at that address was stored as the union type.

Do not lie to the compiler or it will get its revenge.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Finding virtual address of functions in code

[Andrew Haley]

On 07/01/2018 03:19 PM, Mahmood Naderan via gcc wrote:

> Is there any builtin function in C which prints the virtual address
> of functions including the main? I see __builtin_return_address()
> but that returns the “return address”.

#include 
int main() {
  printf("%p\n", main);
}

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: __builtin_isnormal question

[Andrew Haley]

On 06/04/2018 09:44 PM, Steve Ellcey wrote:
> 0.0 is a normal (as opposed to a denormalized) number isn't
> it?  Or is zero special?

In addition to the other answers, yes, zero is special.  Normal numbers
in IEEE-754 have an implicit leading 1 bit.  Zero is a case of a denormal
number.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Please support the _Atomic keyword in C++

[Andrew Haley]

On 05/15/2018 11:01 AM, Rodrigo V. G. wrote:
> I tried to use __atomic_fetch_add in C++ with a volatile (non _Atomic) 
> variable,
> and it seems to generate the same assembler code.
> The only difference that I saw was that with _Atomic
> it generates a "mfence" instruction after initialization but with
> volatile it does not.

That's what should happen on x86.

> So I think it might not provide the same guarantees.

I think it does.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: fminnm/fmaxnm generation in aarch64

[Andrew Haley]

On 07/05/18 18:08, Indu Bhagat wrote:

[Trying to get some feedback. I earlier posted on gcc-help a week ago]

In tree.def -

/* Minimum and maximum values.  When used with floating point, if both
    operands are zeros, or if either operand is NaN, then it is unspecified
    which of the two operands is returned as the result. */
DEFTREECODE (MIN_EXPR, "min_expr", tcc_binary, 2)
DEFTREECODE (MAX_EXPR, "max_expr", tcc_binary, 2)

I see that the compiler cannot simplify an expression like
((a<b)?a:b) into a MIN_EXPR for FP data types without additional flags
(-ffinite-math-only -fno-signed zeros flags).

Q1: It is not clear to me what is the fundamental reason of the
     "unspecified behaviour" of MIN_EXPR/MAX_EXPR in case of floating point
     operands ?

(For the sake of discussing what I write hereafter, assume that
fminnm/fmaxnm instructions offer better performance than fcsel/fcmp). So, two
further questions:

Q2. If one wants the compiler to generate fminnm/fmaxnm instructions, while
     conforming with IEEE standard, the way to do that will be to use math
     builtins fmin()/fmax(). Is this correct understanding?


Yes.


Q3. What will it take for the compiler transform high-level language
     floating point construct like ((a<b)?a:b) to a fminnm/fmaxnm insn for
     aarch64 targets?


You'd have to use -ffast-math or .ffinite-math-only.  The meaning of the 
expression
((a<b)?a:b) is not the same as fminnm.  It would be incorrect for GCC to 
translate
that expression into fminnm.

--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andrew Haley]

On 04/25/2018 03:04 PM, Jonathan Wakely wrote:
> On 25/04/18 14:59 +0100, Andrew Haley wrote:
>> On 04/25/2018 02:56 PM, Jason Merrill wrote:
>>> The warning by default seems sufficient to me.
>>
>> Yes.  We've been bitten by this a few times, with mysterious crashes.
>> I'm not sure it even makes sense only to be a warning, but I guess
>> that's up to the C++ TC.
> 
> It's not always possible for the compiler to prove that flowing off
> the end never happens, even if the program state ensures that it can't
> (e.g. by all callers enforcing the function's preconditions
> correctly). So making it ill-formed is deemed too draconian whenever
> this gets discussed.

Sure.  Having said that, the cases that bit me were those where control
always flowed off the end, i.e. the function contained no return statement.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andrew Haley]

On 04/25/2018 02:56 PM, Jason Merrill wrote:
> The warning by default seems sufficient to me.

Yes.  We've been bitten by this a few times, with mysterious crashes.
I'm not sure it even makes sense only to be a warning, but I guess
that's up to the C++ TC.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andrew Haley]

On 04/25/2018 01:23 PM, Jonathan Wakely wrote:

> We enabled -Wreturn-type by default in GCC 8, so code using the
> extension will get warnings even without -Wall now. Users might want
> to use -Werror=return-type to ensure they aren't bitten by the new
> optimizations that assume control never reaches the end of a
> non-void function.

But ISO C++ allows control to reach the end of main(), and
automagically returns 0.  I guess you didn't mean that, but your reply
was confusing.

N4659, Section 6.6.1 Para 5:

 If control flows off the end of the compound-statement of main, the
 effect is equivalent to a return with operand 0 (see also 18.3).

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Bugzilla admin?

[Andrew Haley]

On 10/01/18 14:33, Jakub Jelinek wrote:
> On Wed, Jan 10, 2018 at 02:30:39PM +0000, Andrew Haley wrote:
>> I don't seem to have write access to bugs in GCC Bugzilla.  I'm pretty
>> sure I used to have it.  Who do I contact?  Thanks.
> 
> You need to use the @gcc.gnu.org account to have write access to bugzilla,
> using some other account usually doesn't work.

Aha!  That was it, thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Bugzilla admin?

[Andrew Haley]

I don't seem to have write access to bugs in GCC Bugzilla.  I'm pretty
sure I used to have it.  Who do I contact?  Thanks.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: TLS details on Linux for x86 and x64

[Andrew Haley]

On 03/12/17 10:50, Jakub Jelinek wrote:
> On Sat, Dec 02, 2017 at 05:00:23PM +0000, Andrew Haley wrote:
>> On 02/12/17 14:04, Liu Hao wrote:
>>>
>>> 0) What is the magical `@tpoff` suffix supposed to do? The `@ntpoff` and
>>> `@dtpoff` things are documented in System V ABI but there doesn't seem
>>> to be anything about `@tpoff`.
>>> 1) How does LD tell that `b` (a thread-local integer) is different from
>>> `a` (a static integer)? `a` is apparently offset from RIP, but what
>>> thing is `b` offset from?
>>> 2) TLS initializers are placed into specially named sections. The
>>> sections will have the names like `.tls$XXX` where `$XXX` is used to
>>> sort these sections and discarded thereafter. How is LD supposed to
>>> associate the section containing the initializer with the symbol of
>>> object being initialized, without disordering?
>>>
>>> Any help will be appreciated.
>>
>> Have you read
>>
>> https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt
>>
>> ?
> 
> Well, for GNU TLS (rather than GNU2) you want to read
> https://www.akkadia.org/drepper/tls.pdf

Ah, thanks.  I thought that it was much the same.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: TLS details on Linux for x86 and x64

[Andrew Haley]

On 02/12/17 14:04, Liu Hao wrote:
> 
> 0) What is the magical `@tpoff` suffix supposed to do? The `@ntpoff` and
> `@dtpoff` things are documented in System V ABI but there doesn't seem
> to be anything about `@tpoff`.
> 1) How does LD tell that `b` (a thread-local integer) is different from
> `a` (a static integer)? `a` is apparently offset from RIP, but what
> thing is `b` offset from?
> 2) TLS initializers are placed into specially named sections. The
> sections will have the names like `.tls$XXX` where `$XXX` is used to
> sort these sections and discarded thereafter. How is LD supposed to
> associate the section containing the initializer with the symbol of
> object being initialized, without disordering?
> 
> Any help will be appreciated.

Have you read

https://www.fsfla.org/~lxoliva/writeups/TLS/RFC-TLSDESC-x86.txt

?

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: atomic_thread_fence() semantics

[Andrew Haley]

On 19/10/17 14:04, Sebastian Huber wrote:
> On 19/10/17 14:18, Andrew Haley wrote:
>> On 19/10/17 13:10, Jonathan Wakely wrote:
>>> There are no atomic operations on atomic objects here, so the fence
>>> doesn't synchronize with anything.
>> Really?  This seems rather unhelpful, to say the least.
>>
>> An atomic release operation X in thread A synchronizes-with an acquire
>> fence F in thread B, if
>>
>>  there exists an atomic read Y (with any memory order)
>>  Y reads the value written by X (or by the release sequence headed by X)
>>  Y is sequenced-before F in thread B
>>
>> In this case, all non-atomic and relaxed atomic stores that
>> happen-before X in thread A will be synchronized-with all non-atomic
>> and relaxed atomic loads from the same locations made in thread B
>> after F.
> 
> Where is the acquire fence or a load in the example?

In another thread.  :-)

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: atomic_thread_fence() semantics

[Andrew Haley]

On 19/10/17 13:10, Jonathan Wakely wrote:
> There are no atomic operations on atomic objects here, so the fence
> doesn't synchronize with anything.

Really?  This seems rather unhelpful, to say the least.

An atomic release operation X in thread A synchronizes-with an acquire
fence F in thread B, if

there exists an atomic read Y (with any memory order)
Y reads the value written by X (or by the release sequence headed by X)
Y is sequenced-before F in thread B

In this case, all non-atomic and relaxed atomic stores that
happen-before X in thread A will be synchronized-with all non-atomic
and relaxed atomic loads from the same locations made in thread B
after F.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: atomic_thread_fence() semantics

[Andrew Haley]

On 19/10/17 12:58, Mattias Rönnblom wrote:
> I have this code:
> 
> #include 
> 
> int ready;
> int message;
> 
> void send_x4711(int m) {
>  message = m*4711;
>  atomic_thread_fence(memory_order_release);
>  ready = 1;
> }
> 
> When I compile it with GCC 7.2 -O3 -std=c11 on x86_64 it produces the 
> following code:
> 
> send_x4711:
> .LFB0:
> .LVL0:
>  imuledi, edi, 4711
> .LVL1:
>  mov DWORD PTR ready[rip], 1
>  mov DWORD PTR message[rip], edi
>  ret
> 
> I expected the store to 'message' and 'ready' to be in program order.
> 
> Did I misunderstand the semantics of 
> atomic_thread_fence+memory_order_release?

No, you did not.  This looks like a bug.  Please report it.

The tree dump looks OK:

send_x4711 (int m)
{
  int _1;

   [100.00%]:
  _1 = m_2(D) * 4711;
  message = _1;
  __atomic_thread_fence (3);
  ready = 1;
  return;

}

It looks like a bug in the lowering pass.

;; __atomic_thread_fence (3);

is lowered to

(nil)

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: GCC aliasing extension for C

[Andrew Haley]

On 18/09/17 10:48, Florian Weimer wrote:
> Is this a property of the char type, or would other types work as well, 
> for example, double or long double?

It has to be a character type, I believe.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: gcc behavior on memory exhaustion

[Andrew Haley]

On 09/08/17 14:05, Andrew Roberts wrote:
> 2) It would be nice to see some sort of out of memory error, rather than 
> just an ICE.

There's nothing we can do: the kernel killed us.  We can't emit any
message before we die.  (killed) tells you that we were killed, but
we don't know who done it.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Overwhelmed by GCC frustration

[Andrew Haley]

On 31/07/17 17:12, Oleg Endo wrote:
> On Mon, 2017-07-31 at 15:25 +0200, Georg-Johann Lay wrote:
>> Around 2010, someone who used a code snipped that I published in
>> a wiki, reported that the code didn't work and hang in an
>> endless loop.  Soon I found out that it was due to some GCC
>> problem, and I got interested in fixing the compiler so that
>> it worked with my code.
>>
>> 1 1/2 years later, in 2011, [...]
> 
> I could probably write a similar rant.  This is the life of a
> "minority target programmer".  Most development efforts are being
> done with primary targets in mind.  And as a result, most changes
> are being tested only on such targets.
> 
> To improve the situation, we'd need a lot more target specific tests
> which test for those regressions that you have mentioned.  Then of
> course somebody has to run all those tests on all those various
> targets.  I think that's the biggest problem.  But still, with a
> test case at hand, it's much easier to talk to people who have
> silently introduced a regression on some "other" targets.  Most of
> the time they just don't know.

It's a fundamental problem for compilers, in general: every
optimization pass wants to be the last one, and (almost?) no-one who
writes a pass knows all the details of all the subsequent passes.  The
more sophisticated and subtle an optimization, the more possibility
there is of messing something up or confusing someone's back end or a
later pass.  We've seen this multiple times, with apparently
straightforward control flow at the source level turning into a mess
of spaghetti in the resulting assembly.  But we know that the
optimization makes sense for some kinds of program, or at least that
it did at the time the optimization was written.  However, it is
inevitable that some programs will be made worse by some
optimizations.  We hope that they will be few in number, but it
really can't be helped.

So what is to be done?  We could abandon the eternal drive for more
and more optimizations, back off, and concentrate on simplicity and
robustness at the expens of ultimate code quality.  Should we?  It
would take courage, and there will be an eternal pressume to improve
code.  And, of course, we'd risk someone forking GCC and creating the
"superoptimized GCC" project, starving FSF GCC of developers.  That's
happened before, so it's not an imaginary risk.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: What kind of data would be put into code section?

[Andrew Haley]

On 28/06/17 05:00, Benxi Liu wrote:

> I'm using GCC 5.4.0.  I know that in some situations, GCC will put
> data into .text section, to improve performance. I know one case is
> jump table, but I'm still curious about other cases. What kind of data
> will be put into executable sections? Is there any way to avoid this?
> Any ideas?

On ARM, PC-relative loads have a fairly short range.  So:

float d() {
  return 3.141592653589;
}

d:
ldr s0, .LC0
ret

.align  2
.LC0:
.word   1078530011

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: "Uninitialized array" warnings by c++ with -O2

[Andrew Haley]

On 07/06/17 14:45, K wrote:
> And I found that that a version which I beleve mustn't have aliasing 
> problems still generates same warnings.

It still has aliasing problems: you can't make them magically go away
by using an intermediate uint8_t*.

You're doing this:

 struct udp_pseudo {
 uint32_t src;
 uint32_t dst;
 uint8_t  z;
 uint8_t  proto;
 uint16_t len;
 } tmp;
...

 auto ret = calc_16bit_checksum_part((uint8_t*), sizeof(tmp), 0);

 static uint32_t calc_16bit_checksum_part(uint8_t* buf, int len,  
uint32_t ret) {
 struct ui16{
 uint16_t d;
 };
 ui16 *ptr = (ui16*)buf;

There's no need for any of this messing about with pointer casts, as has
been explained.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: "Uninitialized array" warnings by c++ with -O2

[Andrew Haley]

On 07/06/17 10:15, Kirill Yu Berezin wrote:
> My question is. Is this an expected behaviour or I must report a bug ?

It's not a bug: your code displays undefined behaviour: you're casting
a pointer to struct udp_pseudo fields to an array of uint16_t.  This
is never well-defined in C++, but if you really want to do this kind
of thing, use -fno-strict-aliasing.

See also
http://www.microhowto.info/howto/calculate_an_internet_protocol_checksum_in_c.html

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

[PATCH] Loop splitting breaks with loops of pointer type

[Andrew Haley]

Loop splitting is fine when the control variable is of integer type,
but when it is a pointer type the upper bound of the new loop is
calculated incorrectly.
The calculation should be guard_init + (end-beg), but instead we do
guard_init - (end-beg).

Fixed thusly.  Bootstrapped, regtested.

OK?

Andrew.


2017-03-08  Andrew Haley  <a...@redhat.com>

PR tree-optimization/79894
* tree-ssa-loop-split.c (compute_new_first_bound): When
calculating the new upper bound, (END-BEG) should be added, not
subtracted.

Index: gcc/tree-ssa-loop-split.c
===
--- gcc/tree-ssa-loop-split.c   (revision 245948)
+++ gcc/tree-ssa-loop-split.c   (working copy)
@@ -436,7 +436,6 @@
   if (POINTER_TYPE_P (TREE_TYPE (guard_init)))
 {
   enddiff = gimple_convert (stmts, sizetype, enddiff);
-  enddiff = gimple_build (stmts, NEGATE_EXPR, sizetype, enddiff);
   newbound = gimple_build (stmts, POINTER_PLUS_EXPR,
   TREE_TYPE (guard_init),
   guard_init, enddiff);


2017-03-08  Andrew Haley  <a...@redhat.com>

PR tree-optimization/79894
* gcc.dg/tree-ssa/pr79943.c: New test.

Index: gcc/testsuite/gcc.dg/tree-ssa/pr79943.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/pr79943.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/pr79943.c (revision 0)
@@ -0,0 +1,40 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -fsplit-loops -fdump-tree-lsplit-details" } */
+/* { dg-require-effective-target int32plus } */
+
+#ifdef __cplusplus
+extern "C" void abort (void);
+#else
+extern void abort (void);
+#endif
+
+typedef struct {
+  int n;
+} region_t;
+
+void set (region_t *region) __attribute__((noinline));
+void doit (region_t *beg, region_t *end, region_t *limit)
+  __attribute__((noinline));
+
+region_t regions[10];
+
+void
+set (region_t *region) {
+  region->n = 1;
+}
+
+void
+doit (region_t *beg, region_t *end, region_t *limit) {
+  for (region_t *cur = beg; cur < end; cur++) {
+if (cur < limit) {
+  set(cur);
+}
+  }
+}
+
+int
+main (void) {
+  doit([0], [2], [10]);
+  if (regions[1].n != 1)
+abort();
+}

Re: signed int performance question

[Andrew Haley]

On 28/02/17 06:38, Eyal Itkin wrote:
> However, in signed integers, the logical meaning of any relation check
> is only the theoretical meaning of the order relation between the
> numbers in the group Z. Meaning that in a purely theoretical manner "a
> + b < c" is a relation order that is equivalent to "a < c - b" or even
> " 0 < c - b - a". The only exception here is about any possible
> integer overflow (above MAX_INT) or underflow (below MIN_INT), however
> such cases are specified to be undefined in the C standard, and should
> not harm the possible efficiency of the code generation.

We can't change arithmetic which does not overflow into arithmetic
which might.  We re-order operations where we know that it's safe
to do so, but this one does not look safe to me.

Andrew.

Re: Argument Against Removal of GCJ

[Andrew Haley]

On 22/02/17 05:52, R0b0t1 wrote:
> I have found GCJ to be one of the best methods for bootstrapping
> OpenJDK. No other method of adding support for new architectures that
> does not involve working closely with OpenJDK upstream is known to me.

That doesn't matter any more because OpenJDK has full cross-compiler
support.

> Many of the users of GCJ and GNU Classpath do not know they are users
> and, even if they do know, are not aware that it is being considered
> for removal from the GCC nor aware of this mailing list. The GNU Java
> frontend is often the only usable "JRE" for poorly supported, old, or
> very new systems. Users of these systems need Java environments first
> produced with GCJ or GCJ itself.

I don't think that's true any more: OpenJDK supports just as many
GNU/Linux systems as did GCJ, as far as I know.  Perhaps more.  The
Zero VM allows OpenJDK to run on anything that has a working C++
compiler.

> That the Java capabilities are not receiving development does not mean
> they are not useful, nor is that a good reason to remove them.

That's easy for you to say.  Systems must be maintained or they rot.
We need maintainers.

Andrew.

Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

[Andrew Haley]

On 23/01/17 16:11, Joshua Kinard wrote:
> So now the question is why stack-probing kills this machine on generic MIPS
> code that its smaller cousin is seemingly unaffected by.  I do know that IP27
> has a different set of memory initialization routines in the MIPS code, so is
> it possible that, at the point that _raw_spin_lock_irq is called and the
> stack-probe happens, that there isn't any stack space available because the
> IP27-specific memory init hasn't yet completed?

I'm sorry, but that really is a question for the kernel people.

Andrew.

Re: Odd gcc-6.3.0 code generation on mips64 platform causing kernel Oops

[Andrew Haley]

On 23/01/17 15:26, Joshua Kinard wrote:
> I am not sure what this lone store-doubleword instruction is exactly doing, 
> nor
> can I locate where in the gcc MIPS code it is being generated from. 

It's a stack probe, making sure that there is enough stack space.  Its
only purpose is to provide a SEGV if there is not enough kernel stack.

Look for`-fstack-check' as a GCC argument.


Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 23/01/17 13:41, Jakub Jelinek wrote:
> On Mon, Jan 23, 2017 at 04:51:44AM -0800, Per Bothner wrote:

>> The last part is moot, as we should strive to not move pages and thus break 
>> links.
> 
> I meant updating URLs in the pages when they refer to external web pages
> which move over time (or switch from http to https, or disappear, etc.).  
> Gerald
> does a great job handling that, but if there are too many pages for
> historical purpose only, it will make his work harder.

We can redirect to somewhere else.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 22/01/17 18:41, Per Bothner wrote:
> In my opinion, all/most of these should be restored.

Because of the historical interest?  That's a good point, and perhaps
I was too hasty.  Sorry.

Andrew.

Re: Why are GCC Internals not Specification Driven ?

[Andrew Haley]

On 18/12/16 02:33, Seima Rao wrote:
> Precisely, stuffs like GENERIC, GIMPLE, RTL, gas(inline assembly),
> GCC extensions internals, ... and gnu's own debugging tied to gcc
> (if such exist nowadays), ... are not documented in a specification
> driven way.

That's interesting.  Can you explain what you mean by a specification-
driven way?

Andrew.

Re: libffi maintenance within GCC?

[Andrew Haley]

On 28/10/16 04:03, Ian Lance Taylor wrote:
> On Thu, Oct 27, 2016 at 6:08 AM, Anthony Green  wrote:
>> Is it still important that libffi be included in the GCC tree?
> 
> [ Replying again as last message was bounced as HTML--sorry for the
> duplication.]
> 
> libffi is used by libgo, for much the same reason as it was used by
> libjava, so it needs to come from somewhere.

It has been very convenient for GCC port maintainers to be able to
commit their patches to the GCC tree.

Andrew.

Re: libffi maintenance within GCC?

[Andrew Haley]

On 27/10/16 13:55, Matthias Klose wrote:
> With the removal of libgcj, the only user of libffi in GCC is libgo, however
> there is now no maintainer listed anymore for libffi in the MAINTAINERS file,
> and the libffi subdir is a bit outdated compared to the libffi upstream
> repository (got aware of this by libffi issue #197).  Who would be responsible
> now to update / review libffi patches, just the global reviewers, or should
> libffi be maintained by the libgo maintainers?

libffi has always been maintained by the appropriate back-end maintainers.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 04/10/16 09:39, Rainer Orth wrote:
> Hi Matthias,
> 
>> On 05.09.2016 17:13, Andrew Haley wrote:
>>> As discussed.  I think I should ask a Global reviewer to approve this
>>> one.  For obvious reasons I haven't included the diffs to the deleted
>>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>>> if anyone would like to try it.
>>
>> still breaks bootstraps when configured with --enable-objc-gc.
>>
>> the immediate step should be to fix the bootstrap failure, as an additional 
>> step
>> to remove boehm-gc from the gcc sources and be able to use an external 
>> boehm-gc.
> 
> the first part is handled by my unreviewed patch
> 
>   https://gcc.gnu.org/ml/gcc-patches/2016-09/msg02437.html

Looks obvious to me, fixes bootstrap.  I think no-one will complain
if you check it in.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 02/10/16 14:27, Andreas Schwab wrote:
> Things we may want to remove:
> 
> - references to java in contrib (download_ecj, gcc_update,
>   patch_tester.sh, update-copyright.py)
> - GCJ, GCJ_FOR_BUILD, GCJ_FOR_TARGET in Makefiles.tpl and configure.ac
> - LIBGCJ_SONAME in config/i386/{cygwin.h,mingw32.h}
> - references to java in install.texi

Yes, that's true.  Thanks for doing the search.

Andrew.

Re: [PATCH] Fix bootstrap with --enable-languages=all,go

[Andrew Haley]

On 30/09/16 23:16, Rainer Orth wrote:
> me too, though mostly to have maximum test coverage (primarily on
> Solaris).  As expected, a x86_64-apple-darwin16 bootstrap with
> --enable-objc-gc just failed for me.  I'm testing the following patch
> (on top of Jakub's).
> 
>   Rainer
> 
> 
> 2016-10-01  Rainer Orth  
> 
>   * configure.ac (target_libraries): Readd target-boehm-gc.
>   Restore --enable-objc-gc handling.
>   * configure: Regenerate.

Thanks everybody.  My apologies.

Andrew.

Re: Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion

[Andrew Haley]

On 30/09/16 17:38, Rainer Orth wrote:
> but both Per and Tom are still libcpp maintainers, so no need to add
> them to the write-after-approval list.

Ooh, I had no idea.  Will fix, thanks.

Andrew.

Move Per Bothner, Andrew Haley, and Tom Tromey to write-after approval after GCJ deletion

[Andrew Haley]

Pushed.

2016-09-30  Andrew Haley  <a...@redhat.com>

* MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to
write-after approval after GCJ deletion.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 240658)
+++ MAINTAINERS (working copy)
@@ -155,9 +155,6 @@
 c++Jason Merrill   <ja...@redhat.com>
 c++Nathan Sidwell  <nat...@codesourcery.com>
 go Ian Lance Taylor<i...@airs.com>
-java   Per Bothner <p...@bothner.com>
-java   Andrew Haley<a...@redhat.com>
-java   Tom Tromey  <tro...@redhat.com>
 objective-c/c++Mike Stump  <mikest...@comcast.net>
 objective-c/c++Iain Sandoe <i...@codesourcery.com>

@@ -352,6 +349,7 @@
 Andrea Bona<andrea.b...@st.com>
 Paolo Bonzini  <bonz...@gnu.org>
 Neil Booth <n...@daikokuya.co.uk>
+Per Bothner <p...@bothner.com>
 Robert Bowdidge<bowdi...@apple.com>
 Joel Brobecker <brobec...@gnat.com>
 Dave Brolley   <brol...@redhat.com>
@@ -425,6 +423,7 @@
 Wei Guozhi <car...@google.com>
 Mostafa Hagog      <ha...@gcc.gnu.org>
 Olivier Hainque<hain...@adacore.com>
+Andrew Haley   <a...@redhat.com>
 Stuart Hastings<stu...@apple.com>
 Michael Haubenwallner  
<michael.haubenwall...@ssi-schaefer.com>
 Pat Haugen <pthau...@us.ibm.com>
@@ -608,6 +607,7 @@
 Philipp Tomsich
<philipp.toms...@theobroma-systems.com>
 Konrad Trifunovic  <konrad.trifuno...@inria.fr>
 Markus Trippelsdorf<mar...@trippelsdorf.de>
+Tom Tromey  <tro...@redhat.com>
 Martin Uecker  <uec...@eecs.berkeley.edu>
 David Ung  <dav...@mips.com>
 Neil Vachharajani  <nvach...@gmail.com>

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 05/09/16 17:25, Gerald Pfeifer wrote:
> And here is the patch for the web pages.
> 
> Note I did not include all the removed java/* contents.  Is there
> anything particular you'd like to retain there?

No, please delete it all.

Thanks,

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 30/09/16 11:27, Marek Polacek wrote:
> Can we move forward with this patch, then?

I've been travelling for several weeks.  However, I'm back at my desk
now, so I can move this forward.  I have all the approvals and
everybody has had time to respond.  However, I'll need to pull some
more recent changes into my tree and merge again.

Andrew.

Re: Is this FE bug or am I missing something?

[Andrew Haley]

On 12/09/16 20:41, Igor Shevlyakov wrote:

> It would be beneficial to make the behaviour consistent between
> those 2 cases.

You've got two cases of undefined behaviour.  What benefit
is there from making two cases of UB consistent with each other?
It's not worth the effort of changing the compiler or of slowing
it down for even a nanosecond to achieve spurious "consistency",
IMO.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 10/09/16 12:59, NightStrike wrote:
> Could we at least reach out and see if there's someone else who could
> be the maintainer?  I noticed gcj patches recently, so there's still
> interest.

1.  It's too late.  We have been discussing this for a long time, and
we're now doing what we decided.

2.  Maintaining GCJ requires a lot of knowledge of both Java and GCC
internals.  There are very few people in the world with that
knowledge, and I'm fairly sure I know them by name.

3.  The Classpath library is very old and is unmaintained.  The only
practical way to update GCJ would be to use the OpenJDK class
libraries instead, but updating GCJ to use those class libraries is a
very substantial job.

So, I cannot prevent anyone from coming along to maintain GCJ, and
neither would I want to.  However, such a proposal would have to be
credible.  It is a multi-engineer-year commitment, and not just any
ordinary engineers.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 05/09/16 17:15, Richard Biener wrote:
> On September 5, 2016 5:13:06 PM GMT+02:00, Andrew Haley <a...@redhat.com> 
> wrote:
>> As discussed.  I think I should ask a Global reviewer to approve this
>> one.  For obvious reasons I haven't included the diffs to the deleted
>> gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
>> is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
>> if anyone would like to try it.
> 
> Isn't there also java specific C++ frontend parts?

There certainly are, but deleting them without breaking anything else
is going to be rather delicate.  I'm trying to do this one step at a
time, rather cautiously.

Andrew.

Re: [PATCH] Delete GCJ

[Andrew Haley]

On 05/09/16 16:29, Matthias Klose wrote:
> Please consider removing boehm-gc as well.  The only other user is
> --enable-objc-gc, which better should use an external boehm-gc.

I can do that, but I do not want to do so with this patch.

Andrew.

[PATCH] Delete GCJ

[Andrew Haley]

As discussed.  I think I should ask a Global reviewer to approve this
one.  For obvious reasons I haven't included the diffs to the deleted
gcc/java and libjava directories.  The whole tree, post GCJ-deletion,
is at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-deletion-branch
if anyone would like to try it.

Andrew.


2016-09-05  Andrew Haley  <a...@redhat.com>

* Makefile.def: Remove libjava.
* Makefile.tpl: Likewise.
* Makefile.in: Regenerate.
* configure.ac: Likewise.
* configure: Likewise.
* gcc/java: Remove.
* libjava: Likewise.

Index: Makefile.in
===
--- Makefile.in (revision 239988)
+++ Makefile.in (working copy)
@@ -322,8 +322,6 @@
 HOST_LIBELFLIBS = @libelflibs@
 HOST_LIBELFINC = @libelfinc@

-EXTRA_CONFIGARGS_LIBJAVA = @EXTRA_CONFIGARGS_LIBJAVA@
-
 # --
 # Programs producing files for the BUILD machine
 # --
@@ -1007,7 +1005,6 @@
 maybe-configure-target-winsup \
 maybe-configure-target-libgloss \
 maybe-configure-target-libffi \
-maybe-configure-target-libjava \
 maybe-configure-target-zlib \
 maybe-configure-target-boehm-gc \
 maybe-configure-target-rda \
@@ -1174,7 +1171,6 @@
 all-target: maybe-all-target-winsup
 all-target: maybe-all-target-libgloss
 all-target: maybe-all-target-libffi
-all-target: maybe-all-target-libjava
 all-target: maybe-all-target-zlib
 all-target: maybe-all-target-boehm-gc
 all-target: maybe-all-target-rda
@@ -1268,7 +1264,6 @@
 info-target: maybe-info-target-winsup
 info-target: maybe-info-target-libgloss
 info-target: maybe-info-target-libffi
-info-target: maybe-info-target-libjava
 info-target: maybe-info-target-zlib
 info-target: maybe-info-target-boehm-gc
 info-target: maybe-info-target-rda
@@ -1355,7 +1350,6 @@
 dvi-target: maybe-dvi-target-winsup
 dvi-target: maybe-dvi-target-libgloss
 dvi-target: maybe-dvi-target-libffi
-dvi-target: maybe-dvi-target-libjava
 dvi-target: maybe-dvi-target-zlib
 dvi-target: maybe-dvi-target-boehm-gc
 dvi-target: maybe-dvi-target-rda
@@ -1442,7 +1436,6 @@
 pdf-target: maybe-pdf-target-winsup
 pdf-target: maybe-pdf-target-libgloss
 pdf-target: maybe-pdf-target-libffi
-pdf-target: maybe-pdf-target-libjava
 pdf-target: maybe-pdf-target-zlib
 pdf-target: maybe-pdf-target-boehm-gc
 pdf-target: maybe-pdf-target-rda
@@ -1529,7 +1522,6 @@
 html-target: maybe-html-target-winsup
 html-target: maybe-html-target-libgloss
 html-target: maybe-html-target-libffi
-html-target: maybe-html-target-libjava
 html-target: maybe-html-target-zlib
 html-target: maybe-html-target-boehm-gc
 html-target: maybe-html-target-rda
@@ -1616,7 +1608,6 @@
 TAGS-target: maybe-TAGS-target-winsup
 TAGS-target: maybe-TAGS-target-libgloss
 TAGS-target: maybe-TAGS-target-libffi
-TAGS-target: maybe-TAGS-target-libjava
 TAGS-target: maybe-TAGS-target-zlib
 TAGS-target: maybe-TAGS-target-boehm-gc
 TAGS-target: maybe-TAGS-target-rda
@@ -1703,7 +1694,6 @@
 install-info-target: maybe-install-info-target-winsup
 install-info-target: maybe-install-info-target-libgloss
 install-info-target: maybe-install-info-target-libffi
-install-info-target: maybe-install-info-target-libjava
 install-info-target: maybe-install-info-target-zlib
 install-info-target: maybe-install-info-target-boehm-gc
 install-info-target: maybe-install-info-target-rda
@@ -1790,7 +1780,6 @@
 install-pdf-target: maybe-install-pdf-target-winsup
 install-pdf-target: maybe-install-pdf-target-libgloss
 install-pdf-target: maybe-install-pdf-target-libffi
-install-pdf-target: maybe-install-pdf-target-libjava
 install-pdf-target: maybe-install-pdf-target-zlib
 install-pdf-target: maybe-install-pdf-target-boehm-gc
 install-pdf-target: maybe-install-pdf-target-rda
@@ -1877,7 +1866,6 @@
 install-html-target: maybe-install-html-target-winsup
 install-html-target: maybe-install-html-target-libgloss
 install-html-target: maybe-install-html-target-libffi
-install-html-target: maybe-install-html-target-libjava
 install-html-target: maybe-install-html-target-zlib
 install-html-target: maybe-install-html-target-boehm-gc
 install-html-target: maybe-install-html-target-rda
@@ -1964,7 +1952,6 @@
 installcheck-target: maybe-installcheck-target-winsup
 installcheck-target: maybe-installcheck-target-libgloss
 installcheck-target: maybe-installcheck-target-libffi
-installcheck-target: maybe-installcheck-target-libjava
 installcheck-target: maybe-installcheck-target-zlib
 installcheck-target: maybe-installcheck-target-boehm-gc
 installcheck-target: maybe-installcheck-target-rda
@@ -2051,7 +2038,6 @@
 mostlyclean-target: maybe-mostlyclean-target-winsup
 mostlyclean-target: maybe-mostlyclean-target-libgloss
 mostlyclean-target: maybe-mostlyclean-target-libffi
-mostlyclean-target: maybe-mostlyclean-target-libjava
 mostlyclean-target: maybe-mostlyclean-target-zlib
 mostlyclean-target: maybe-mostlyclean-

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Andrew Haley]

On 26/07/16 15:37, Warren D Smith wrote:
> --the reason I am suggesting this to this forum, is I probably am not capable 
> of
> recoding GCC myself.

> Why not learn from your own history, and do that again, with these two
> extensions?
> (And in the case of uint4_t, it actually would not even BE an
> "extension" since as I said,
> the standard already allows providing other sizes.)

Does your history tell you that sarcasm and abuse works as a way to
get people to do what you want?

Andrew.

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Andrew Haley]

On 26/07/16 14:31, Warren D Smith wrote:
> However, why not provide access to double-precision multiply and
> add-with-carry (subtract with borrow? shift-left?) in the same fashion?
>twofer  x = mul(a,b);  would cause  x.hi and x.lo  to be computed.
>twofer  x = addwithcarry(a,b)   ditto.

unsigned __int128 poo(unsigned long a, unsigned long b) {
  return (__int128)a * b;
}

unsigned __int128 bar(unsigned __int128 a, unsigned long b) {
  return a + b;
}

Andrew.

Re: Symbian support

[Andrew Haley]

On 25/07/16 14:17, fedor...@mail.ru wrote:
> I build for arm cpu. How write this function? Where I can see example 
> implementation? GCC builded with multilib support.

If your ARM cpu has only one core, the function can be empty.  If it
has more than one core, then you must tell GCC which model of ARM it
is and GCC will generate the appropriate instruction.  It's a DMB
instruction.

Andrew.

Re: Symbian support

[Andrew Haley]

On 25/07/16 12:37, fedor...@mail.ru wrote:

> GCC 6.1.0 inserts call to __sync_synchronize and linker fails with
> error: undefined reference to `__sync_synchronize'. If this is bug I
> can send preprocessed file.

This is something that you can provide yourself.  If it's a
single-core cpu the function can be empty.  Either that or you can
build your program with a -mcpu= option which names a recent x86
processor.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 04/07/16 14:43, Jonathan Wakely wrote:
> It doesn't matter how much warning people have to fix such things,
> most of them won't do it. Then at the last minute some poor person has
> to spend days or weeks going through other people's code fixing all
> the problems...

...and breaking everything.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 22/06/16 09:59, Florian Weimer wrote:
> On 06/20/2016 07:40 PM, Andrew Haley wrote:
>> On 20/06/16 18:36, Michael Matz wrote:
>>> I see zero gain by deprecating them and only churn.  What would be the 
>>> advantage again?
>>
>> Correctness.  It is very likely that many of these basic asms are not
>> robust in the face of compiler changes because they don't declare
>> their dependencies and therefore work only by accident.
> 
> But the correctness problem is much more severe with extended asm.  With
> basic asm, the compiler can be conservative.  With extended asm, there
> is an expectation that it is not, and yet many of the constraints out
> there are slightly wrong and can lead to breakage any time.

Yes, that's true.  However, at least in the case of extended asm there
is a chance that the programmer has thought about it.

But anyway, the decision has been made.  None of this matters.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 21/06/16 17:43, Jeff Law wrote:

> I think there's enough resistance to deprecating basic asms within a
> function that we should probably punt that idea.
> 
> I do think we should look to stomp out our own uses of basic asms
> within functions just from a long term maintenance standpoint.
> 
> Finally I think we should continue to bring the implementation of
> basic asms more in-line with expectations and future proofing them
> since I'm having a hard time seeing a reasonable path to deprecating
> their use.

Me too.  I wonder if there's anything else we can do to make basic asm
in a function a bit less of a time bomb.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

Hi,

On 21/06/16 13:08, Michael Matz wrote:

> On Tue, 21 Jun 2016, Andrew Haley wrote:
> 
>>> As said in the various threads about basic asms, all correctness 
>>> problems can be solved by making GCC more conservative in handling 
>>> them (or better said: not making it less conservative).
>>
>> Well, yes.  That's exactly why we've agreed to change basic asms to make 
>> them clobber memory, i.e. to make GCC more conservative.
> 
> Exactly.  But this thread is about something else, see subject.

Well, you brought up the idea of making GCC "less conservative".  But
making GCC less conservative is something that we have not agreed to
do.  So why did you even mention it if it wasn't relevant?

>> Well, maybe.  It's also fairly likely that many work by accident.  IMO 
>> this is more of a statement of hope than any kind of reasonable 
>> expectation.
> 
> Like yours, of course.

Hmm.  The problem is that programmers have false ideas about basic
asms.  I was one of those programmers: I "knew" that basic asms
implicitly clobbered memory, and I was startled to find out I was
wrong.  And I have been a GCC mainatiner for a long time.  I guess it
is possible that all of those uses of basic asm David mentioned are in
fact correct.  It's likely that adding a memory clobber will help.

But some things I have seen (such as changing the floating-point
status register) may not be be reliable without inputs and outputs and
should be fixed.

On the one hand we have the risk of churn, but basic asm in a function
isn't such a great idea anyway.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

Hi,

On 20/06/16 19:01, Michael Matz wrote:

> On Mon, 20 Jun 2016, Andrew Haley wrote:
> 
>> On 20/06/16 18:36, Michael Matz wrote:
>>> I see zero gain by deprecating them and only churn.  What would be the 
>>> advantage again?
>>
>> Correctness.
> 
> As said in the various threads about basic asms, all correctness 
> problems can be solved by making GCC more conservative in handling them 
> (or better said: not making it less conservative).

Well, yes.  That's exactly why we've agreed to change basic asms to
make them clobber memory, i.e. to make GCC more conservative.

> If you talk about cases where basic asms diddle registers expecting GCC to 
> have placed e.g. local variables into specific ones (without using local 
> reg vars, or extended asm) I won't believe any claims ...
> 
>> It is very likely that many of these basic asms are not
>> robust
> 
> ... of them being very likely without proof.  They will have stopped
> working with every change in compilation options or compiler
> version.  In contrast I think those that did survive a couple years
> in software very likely _are_ correct, under the then documented (or
> implicit) assumptions.  Those usually are: clobbers and uses memory,
> processor state and fixed registers.

Well, maybe.  It's also fairly likely that many work by accident.  IMO
this is more of a statement of hope than any kind of reasonable
expectation.

>> in the face of compiler changes because they don't declare their 
>> dependencies and therefore work only by accident.
> 
> Then the compiler better won't change into less conservative
> handling of basic asms.

Repeat, repeat: the change being made is to make gcc MORE
conservative.

> You see, the experiment shows that there's a gazillion uses of basic
> asms out there.  Deprecating them means that each and every one of
> them (for us alone that's 540 something, including testsuite and
> boehm) has to be changed from asm("body") into asm("body" : : :
> "memory") (give and take some syntax for also clobbering flags).
> Alternatively rewrite the body to actually make use of extended asm.
> I guarantee you that a non-trivial percentage will be wrong _then_
> while they work fine now.  Even if it weren't so it still would be
> silly if GCC simply could regard the former as the latter
> internally.

That's what we're doing.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 20/06/16 18:36, Michael Matz wrote:
> I see zero gain by deprecating them and only churn.  What would be the 
> advantage again?

Correctness.  It is very likely that many of these basic asms are not
robust in the face of compiler changes because they don't declare
their dependencies and therefore work only by accident.

There are some correct basic asms.  For example,

  asm("nop")

There are some others too, once we've made the change to have basic
asms clobber memory.  These include syscalls which are implemented
by using named register variables.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 20/06/16 15:52, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote:
>> On 20/06/16 15:42, Segher Boessenkool wrote:
>>> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
>>>> On 20/06/16 14:50, Segher Boessenkool wrote:
>>>>> If basic asm is deprecated, that means some time later it will be
>>>>> removed, at which time an asm without : can be used as extended asm
>>>>
>>>> Not exactly: it'd be an asm with no inputs, no outputs, and no
>>>> clobbers i.e. no effects.
>>>
>>> I'm not sure what you mean?  It will be treated exactly the same as
>>> basic asm (it is now, anyway).  And it has an effect, it is volatile
>>> after all, not having any outputs?
>>
>> Well, you didn't say that it was volatile: and unless it really is
>> an asm volatile (not just an asm) an extended asm with no effects
>> is a statement with no effects.
> 
> An extended asm without outputs is always volatile (exactly because
> it would be useless otherwise).

Oh, I see what you mean now.  Yes, point taken.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 20/06/16 15:42, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
>> On 20/06/16 14:50, Segher Boessenkool wrote:
>>> If basic asm is deprecated, that means some time later it will be
>>> removed, at which time an asm without : can be used as extended asm
>>
>> Not exactly: it'd be an asm with no inputs, no outputs, and no
>> clobbers i.e. no effects.
> 
> I'm not sure what you mean?  It will be treated exactly the same as
> basic asm (it is now, anyway).  And it has an effect, it is volatile
> after all, not having any outputs?

Well, you didn't say that it was volatile: and unless it really is
an asm volatile (not just an asm) an extended asm with no effects
is a statement with no effects.


Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 20/06/16 14:50, Segher Boessenkool wrote:
> If basic asm is deprecated, that means some time later it will be
> removed, at which time an asm without : can be used as extended asm

Not exactly: it'd be an asm with no inputs, no outputs, and no
clobbers i.e. no effects.

Andrew.

Re: Deprecating basic asm in a function - What now?

[Andrew Haley]

On 20/06/16 08:00, Andrew Pinski wrote:
> +   /* Acceptable.  */
> +   asm (" "); /* { dg-warning "Deprecated: asm in function without
> extended syntax" } */

This is incorrect English.  It should be

"Deprecated: asm without extended syntax in function"

because it's the asm that is missing the extended syntax, not the
function.

Andrew.

Re: [DOC PATCH] Rewrite docs for inline asm

[Andrew Haley]

On 04/04/14 20:48, dw wrote:
> I do not have write permissions to check this patch in.

We must fix that.

Andrew.

Re: [PATCH] Make basic asm implicitly clobber memory

[Andrew Haley]

On 05/20/2016 07:50 AM, David Wohlferd wrote:

> At a minimum, suddenly forcing an unexpected/unneeded memory clobber
> can adversely impact the optimization of surrounding code.  This can
> be particularly annoying if the reason for the asm was to improve
> performance.  And adding a memory clobber does add a dependency of
> sorts, which might cause the location of the asm to shift in an
> unfortunate way.  And there's always the long-shot possibility that
> some weird quirk or (very) badly-written code will cause the asm to
> flat out fail when used with a memory clobber.  And if this change
> does produce any of these problems, I feel pity for whoever has to
> track it down.

OTOH, if a memory clobber does change code gen it probably changes it
in a way which better fits user expectations, and perhaps it fixes a
bug.  That's a win, and it is far, far more important than any other
consideration.

Given that a basic asm statements has neither inputs nor outputs, it
must have side effects to be useful.  All this patch does is recognize
that fact.  I'm not saying your scenario won't occur, but it won't in
the majority of cases.

> I realize deprecation/removal is drastic.  Especially since basic
> asm (mostly) works as is.  But fixing memory clobbers while leaving
> the rest broken feels like half a solution, meaning that some day
> we're going to have to fiddle with this again.

Yes, we will undoubtedly have to fiddle with basic asm again.  We
should plan for deprecation.

But I think you're close to the all-or-nothing fallacy: that because
this patch doesn't solve all the problems with basic asm, it isn't
worth having.

Andrew.

Re: GNU C: Implicit int and implicit function definitions

[Andrew Haley]

On 05/20/2016 10:02 AM, Florian Weimer wrote:
> On 05/20/2016 10:30 AM, lh mouse wrote:
>> Implicit function declarations result in warnings since C99 or GNU99 and 
>> '-pedantic-errors' turns them into errors.
>> The same goes for implicit return types.
> 
> The warnings typically do not stop the build, and thus are not really 
> helpful when you are looking at binaries.

C99 Rationale sez:

   A new feature of C99: In C89, all type specifiers could be omitted
   from the declaration specifiers in a declaration. In such a case
   int was implied. The Committee decided that the inherent danger of
   this feature outweighed its convenience, and so it was removed. The
   effect is to guarantee the production of a diagnostic that will
   catch an additional category of programming errors. After issuing
   the diagnostic, an implementation may choose to assume an implicit
   int and continue to translate the program in order to support
   existing source code that exploits this feature.

Given this, I do not understand why GCC does not treat implicit int as
a hard error.

Andrew.

Re: [PATCH] Make basic asm implicitly clobber memory

[Andrew Haley]

On 06/05/16 07:35, David Wohlferd wrote:

> 1) I'm not clear precisely what problem this patch fixes.  It's true
> that some people have incorrectly assumed that basic asm clobbers
> memory and this change would fix their code.  But some people also
> incorrectly assume it clobbers registers.  I assume that's why Jeff
> Law proposed making basic asm "an opaque blob that
> read/write/clobber any register or memory location."

A few more things:

Jeff Law did propose this, but it's impossible to do because it
inevitably causes reload failures.

My argument in support of Bernd's proposal is that it makes sense from
a *practical* software reliability point of view.  It wouldn't hurt,
and might fix some significant bugs.  It's similar to the targets
which always implicitly clobber "cc".  It corresponds to what I always
assumed basic asm did, and I'm sure that I'm not alone.  This change
might fix some real bugs and it is extremely unlikely to break
anything.

Andrew.

Re: Please, take '-Wmisleading-indentation' out of -Wall

[Andrew Haley]

On 05/05/2016 07:56 PM, Antonio Diaz Diaz wrote:
> Take this example http://gcc.gnu.org/ml/gcc-patches/2016-03/msg00261.html
> 
> The user sees this:
> 
>if (flagA)  // GUARD
>  foo (0);  // BODY
> #if SOME_CONDITION_THAT_DOES_NOT_HOLD
>if (flagB)
> #endif
>  foo (1);  // NEXT

Surely this misleading code is exactly what we should be warning about.

It could be like this, and far less misleadingly:

   if (flagA)  // GUARD
 foo (0);  // BODY

#if SOME_CONDITION_THAT_DOES_NOT_HOLD
   if (flagB)
#endif
   {
 foo (1);  // NEXT
   }

Better for the reader, nothing to warn about.

Andrew.

Re: [patch] Don't encode the minor version in the gcj abi version

[Andrew Haley]

On 04/28/2016 12:45 PM, Matthias Klose wrote:
> yes, that looks good. Can't approve it myself.

OK.

Andrew.

Re: [patch] Don't encode the minor version in the gcj abi version

[Andrew Haley]

On 28/04/16 08:55, Matthias Klose wrote:
> Ok for the 6 branch and the trunk?

OK,

Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Andrew Haley]

On 04/19/2016 03:37 PM, Pedro Alves wrote:
> On 04/19/2016 02:25 PM, Andrew Haley wrote:
>> On 04/19/2016 02:19 PM, Michael Matz wrote:
>>
>>> Well, yeah, that's traditional insn caches on multiple cores.  From
>>> user space you need kernel help for this, doing interprocess
>>> interrupts to flush all such buffers on all cores (or at least those
>>> potentially fetching stuff in the patched region, if such
>>> granularity is possible).  An implementation providing such is
>>> non-broken :)
>>
>> Sure.  If you know of any such facility in Linux userspace, please let
>> me know.  :-)
> 
> Sounds like a job for the sys_membarrier system call:
> 
>  https://lkml.org/lkml/2015/3/18/531
>  https://lwn.net/Articles/369567/
> 
> I think it's available in Linux 4.3+.

So it is, thanks.  I'm guessing that might be good enough for full
instruction synchronization barriers, but from looking at the kernel
source I can't really tell.

Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Andrew Haley]

On 04/19/2016 02:19 PM, Michael Matz wrote:

> Well, yeah, that's traditional insn caches on multiple cores.  From
> user space you need kernel help for this, doing interprocess
> interrupts to flush all such buffers on all cores (or at least those
> potentially fetching stuff in the patched region, if such
> granularity is possible).  An implementation providing such is
> non-broken :)

Sure.  If you know of any such facility in Linux userspace, please let
me know.  :-)

But there are ways of doing patching sequences which don't require
IPIs across all the cores; which was my point.

> Alternatively the various invalidate cache instructions need to have
> a form that invalidates the i$ on all cores.

I'm fairly sure we haven't got that in the AArch64 architecture.

Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Andrew Haley]

On 18/04/16 18:34, Michael Matz wrote:
> Hi,
> 
> On Mon, 18 Apr 2016, Andrew Haley wrote:
> 
>>>> That may not be safe.  Consider an implementation which looks
>>>> ahead in the instruction stream and decodes the instructions
>>>> speculatively.
>>>
>>> It should go without saying that patching instructions is followed
>>> by whatever means necessary to flush any such caches on a
>>> particular implementation (here after patching the jump, after
>>> patching the rest, and after patching the first insn again,
>>> i.e. three times).
>>
>> That doesn't necessarily help you, though, without an ISB in the reading 
>> thread.
> 
> I don't understand, which reading thread?  We're writing, not reading 
> instructions.  You mean other executing threads? 

Yes.

> I will happily declare any implementation where it's impossible to
> safely patch the instruction stream by flushing the respective
> buffers or other means completely under control of the patching
> machinery, to be broken by design. 

You can declare anything you want, but we have to program for the
architectural specification.

> What failure mode do you envision, exactly?

It's easiest just to quote from the spec:

How far ahead of the current point of execution instructions are
fetched from is IMPLEMENTATION DEFINED. Such prefetching can be
either a fixed or a dynamically varying number of instructions,
and can follow any or all possible future execution paths. For all
types of memory:

   The PE might have fetched the instructions from memory at any
   time since the last Context synchronization operation on that
   PE.

   Any instructions fetched in this way might be executed multiple
   times, if this is required by the execution of the program,
   without being re-fetched from memory. In the absence of an ISB,
   there is no limit on the number of times such an instruction
   might be executed without being re-fetched from memory.

The ARM architecture does not require the hardware to ensure
coherency between instruction caches and memory, even for
locations of shared memory.

So, if you write a bunch of instructions (which might have been
pre-fetched) and then rewrite a NOP to jump to those instructions you
need to make sure that the thread which might be running concurrently
does an ISB.

Note also:

Memory accesses caused by instruction fetches are not required to
be observed in program order, unless they are separated by an ISB
or other context synchronization event.

So, if you modify instruction memory in one thread, other threads may
see those changes in a different order from the writing thread.  Sure,
the writing thread executes the cache maintenance instructions on its
side, but you also need to do something on the side which is executing
the instructions.

I have wondered if it might be a good idea to use an inter-processor
interrupt to force a context synchronization event across all PEs.

Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Andrew Haley]

On 04/18/2016 06:13 PM, Michael Matz wrote:

> On Mon, 18 Apr 2016, Andrew Haley wrote:
> 
>> On 04/15/2016 06:29 PM, Alexander Monakov wrote:
>>
>>> Alternatively: replace first nop with a short forward branch that
>>> jumps over the rest of the pad, patch rest of the pad, patch the
>>> initial forward branch.
>>
>> That may not be safe.  Consider an implementation which looks ahead in
>> the instruction stream and decodes the instructions speculatively.
> 
> It should go without saying that patching instructions is followed by 
> whatever means necessary to flush any such caches on a particular 
> implementation (here after patching the jump, after patching the rest, and 
> after patching the first insn again, i.e. three times).

That doesn't necessarily help you, though, without an ISB in the reading
thread.

Andrew.

Re: [PATCH] [AArch64] support -mfentry feature for arm64

[Andrew Haley]

On 04/15/2016 06:29 PM, Alexander Monakov wrote:

> Alternatively: replace first nop with a short forward branch that
> jumps over the rest of the pad, patch rest of the pad, patch the
> initial forward branch.

That may not be safe.  Consider an implementation which looks ahead in
the instruction stream and decodes the instructions speculatively.  I
suppse you could begin the block of instructions after the branch with
an ISB.  On balance, the trap sounds like the best plan.  We do this
in Java all the time: every method begins with a NOP, and we patch it
either to a trap or to a call to the replacement code.

Andrew.

Re: [wwwdocs,Java] Remove java/status.html

[Andrew Haley]

On 17/04/16 17:09, Gerald Pfeifer wrote:
> My recommendation is to handle that via java/index, which is the
> main page, and redirect other GCJ pages to that one as we remove
> them.
> 
> Like in the following, for java/status.html.
> 
> Are you fine with that?

OK, thanks.

Andrew.

Re: guide me

[Andrew Haley]

On 17/04/16 17:58, J a h a n z e b F a h i m wrote:

> i am a java developer, i want to install gnu java compiler on LINUX
> 7.2 for testing purpose. i already have gcc version 4.8.5 20150623
> (Red Hat 4.8.5-4) (GCC) in my machine. now i want to add gcj in it.
> how can i install it?

It's going to be difficult.  GCJ is no longer supported on recent
Red Hat systems.  You'll have to download sources and follow the
build instructions at https://gcc.gnu.org/install/.

Andrew.

Re: [wwwdocs,Java] java/index.html -- fix formatting on gcc.gnu.org

[Andrew Haley]

On 16/04/16 21:31, Gerald Pfeifer wrote:
> On Sun, 10 Apr 2016, Andrew Hughes wrote:
>>> That said, looking at the page, and how since 2005 nearly all changes
>>> have been maintainance ones from me, is it really worthwhile keeping
>>> this (short of historic reasons)?
>> I guess the next news will be the removal of GCJ during the
>> GCC 7 development period, so its remaining shelf life should
>> be limited anyway.
> 
> Soo, GCC 6 has branched -- would it make sense for you guys to
> start this removal?

Sounds good.  OTOH, I don't think there's any great hurry.

> Somewhat related, any concerns if I were to remove
> https://gcc.gnu.org/java/status.html now?
> 
> ("Status of GCJ as of GCC 3.2" _really_ is rather old.)

It's so old that I don't think it's of any use.  However, I wonder if
it might make more sense to at least have a page saying that GCJ is
gone.

Andrew.

Re: Spurious register spill with volatile function argument

[Andrew Haley]

On 27/03/16 06:57, Michael Clark wrote:

> GCC, Clang folk, any ideas on why there is a stack spill for a
> volatile register argument passed in esi? Does volatile force the
> argument to have storage allocated on the stack? Is this a corner
> case in the C standard? This argument in the x86_64 calling
> convention only has a register, so technically it can’t change
> outside the control of the C "virtual machine” so volatile has a
> vague meaning here.

"volatile" doesn't really mean very much, formally speaking.  Sure, the
standard says "accesses to volatile objects are evaluated
strictly according to the rules of the abstract machine," but nowhere
is it specified exactly what constitutes an access.  (To be precise,
"what constitutes an access to an object that has volatile-qualified
type is implementation-defined.")

So, we have to fall back to tradition.  Traditionally, all volatile
objects are allocated stack slots and all accesses to them are memory
accesses.  This is consistent behaviour, and has been for a long time.
It is also extremely useful when debugging optimized code.

> volatile for scalar function arguments seems to mean: “make this
> volatile and subject to change outside of the compiler” rather than
> being a qualifier for its storage (which is a register).

No, arguments are not necessarily stored in registers: they're passed
in registers, but after function entry function they're just auto
variables and are stored wherever the compiler likes.

Andrew.

Re: Warning for converting (possibly) negative float/double to unsigned int

[Andrew Haley]

On 27/02/16 11:53, Jakub Jelinek wrote:
> On Sat, Feb 27, 2016 at 10:39:59AM +0000, Andrew Haley wrote:
>> On 26/02/16 21:28, Bradley Lucier wrote:
>>> Any advice on how to proceed?  I'd be willing to write and test the few 
>>> lines of code myself if I knew where to put them.
>>
>> The best thing, rather than warning, would be to define this
>> conversion as a GCC extension and implement it consistently
>> everywhere.  Then we wouldn't need a warning, and there'd be
>> one fewer trap.
> 
> I disagree.  That would slow down most of uses that use it when they know
> the floating point value must be non-negative, for the benefit
> of the few that invoke implementation defined behavior.

Would it really slow things down significantly?  If so, perhaps I
can see the point of this restriction.

Andrew.

Re: Warning for converting (possibly) negative float/double to unsigned int

[Andrew Haley]

On 26/02/16 21:28, Bradley Lucier wrote:
> Any advice on how to proceed?  I'd be willing to write and test the few 
> lines of code myself if I knew where to put them.

The best thing, rather than warning, would be to define this
conversion as a GCC extension and implement it consistently
everywhere.  Then we wouldn't need a warning, and there'd be
one fewer trap.

Andrew.

Re: Placement new versus flifetime-dse

[Andrew Haley]

On 02/16/2016 01:16 PM, Jakub Jelinek wrote:
>> > Can someone please tell me Chapter and Verse in the standard, please?
>> > Then I can close this one.
> I'd think [basic.life] describes this.

For the record, I found it in C++98 [class.cdtor]:

  For an object of non-POD class type ... before the constructor
  begins execution ... referring to any non-static member or base
  class of the object results in undefined behavior

Thanks,

Andrew.

Placement new versus flifetime-dse

[Andrew Haley]

I'm fixing a bug which involves initialization of a field of an object
in its placement new function before the constructor is called.  This
is falling foul of DSE, which deletes the field initialization.

I see this:

  @item -fno-lifetime-dse
  @opindex fno-lifetime-dse
  In C++ the value of an object is only affected by changes within its
  lifetime: when the constructor begins, the object has an indeterminate
  value, and any changes during the lifetime of the object are dead when
  the object is destroyed.  Normally dead store elimination will take
  advantage of this; if your code relies on the value of the object
  storage persisting beyond the lifetime of the object, you can use this
  flag to disable this optimization.

I'm quite happy to believe this, and treat my bug simply as an error
between chair and keyboard, but I cannot find the language in the C++
standard which declares that the lifetime of an object begins with its
constructor, and thus any stores into the object performed by
placement new may be deleted.

Can someone please tell me Chapter and Verse in the standard, please?
Then I can close this one.

Thanks,

Andrew.

Re: GCC-Bridge: A Gimple Compiler targeting the JVM

[Andrew Haley]

On 02/02/2016 05:41 PM, Manuel López-Ibáñez wrote:
> Everything is possible! Not sure how hard it would be, though. As
> said, GJC, the Java FE, was doing something similar sometime ago, but
> it has perhaps bit-rotted now.

It is doing something the other way around: bytecode to Gimple.

Andrew.

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 03/01/16 15:52, Matthias Klose wrote:
> No, libgcj versions up to 4.9.3 didn't change the value for releases taken 
> from 
> the same branch. All of 4.9.0, 4.9.1, 4.9.2, 4.9.3 have the same 
> GCJ_CXX_ABI_VERSION. But 5.1, 5.2 and 5.3 have *different* 
> GCJ_CXX_ABI_VERSIONs.
> 
>> > Why change this rule now, at this stage of GCJ's life?
> This was changed by the change of the version schema, an unintential change 
> for 
> GCJ_CXX_ABI_VERSION.  I want to keep it that way, not change it with every 
> release from the gcc-5 branch.

Because effectively we've done an arithmetic shift left on the GCC version
numbering, I guess?  So where we would have had 5.1.1, 5.1.2, 5.1.3, we now
have 5.1, 5.2, 5.3?

If that's the idea, your patch is OK.

Thanks,

Andrew.

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 03/01/16 11:38, Matthias Klose wrote:
> On 02.01.2016 17:11, Andrew Haley wrote:
>> On 02/01/16 15:53, Matthias Klose wrote:
>>>>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include 
>>>>> __GNUC_MINOR__
>>>>>>> anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so 
>>>>>>> that it
>>>>>>> won't change anymore with future releases from the gcc-5 branch?
>>>>>
>>>>> That's safe only if Classpath and libgcj are not changed at all.
>>> why?
>>
>> Because of the way that gcj's linkage works.  If you change any of the
>> vtable/itable indexes your program will crash.
> 
> Right, but this no change compared to the 4.x.y releases.
> 
> This is what I committed to the trunk.
> 
> So what to do with the gcc-5 branch? Apply the same patch to jvm.h, or fix 
> the 
> minor version to 3? The latter would be compatible at least with the 5.3 
> release.

Neither.  If you link a program with libgcj then you need to recompile
it when a new version of libgcj comes along.  It has always been this
way.  Why change this rule now, at this stage of GCJ's life?

Andrew.

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 02/01/16 14:40, Matthias Klose wrote:
> 
> preparing for a test rebuild of the archive, and trying to run gcj-dbtool 
> (from 
> GCC 5) with libgcj16 (from GCC 6):
> 
> $ gcj-dbtool -n /tmp/foo.db
> libgcj failure: gcj linkage error.
> Incorrect library ABI version detected.  Aborting.
> 
> Aborted (core dumped)
> 
> natClassLoader.cc:_Jv_CheckABIVersion checks the ABI version, which is 
> defined as
> 
> libjava/include/jvm.h:#define GCJ_CXX_ABI_VERSION (__GNUC__ * 10 + 
> __GNUC_MINOR__ * 1000)
> 
> so this will be seen with everything directly linked to libgcj with a 
> libgcj16 
> upgraded to GCC 6. So what to do? Bump the soname, or discard this check?

I'd bump the soname.

> In any case, GCJ_CXX_ABI_VERSION should be changed to not include 
> __GNUC_MINOR__ 
> anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so that it 
> won't change anymore with future releases from the gcc-5 branch?

That's safe only if Classpath and libgcj are not changed at all.  I guess
we can guarantee that on the gcc-5 branch?

Andrew.

Re: [patch] [java] bump libgcj soname

[Andrew Haley]

On 02/01/16 15:53, Matthias Klose wrote:
>>> In any case, GCJ_CXX_ABI_VERSION should be changed to not include 
>>> __GNUC_MINOR__
>>> >> anymore.  Maybe for the gcc-5-branch, set it unconditionally to 3 so 
>>> >> that it
>>> >> won't change anymore with future releases from the gcc-5 branch?
>> >
>> > That's safe only if Classpath and libgcj are not changed at all.
> why?

Because of the way that gcj's linkage works.  If you change any of the
vtable/itable indexes your program will crash.

Andrew.

Re: gcc-4.9.1 generating different code between two successive builds

[Andrew Haley]

On 30/12/15 15:33, Georg-Johann Lay wrote:

> Some parts of the compiler use the address of objects to compute
> hashes, but I don't remember which part(s) actually do this.  That
> technique can lead to different code for different runs of the
> compiler even on the same system.  This is hard to reproduce as it
> depends on how the OS is supplying memory, and it might depend on
> the "history" of the machine and the actual OS.

... and many Linux kernels deliberately randomize memory layout to
provide some protection from buffer overflow attacks.

Andrew.

Re: basic asm and memory clobbers - Proposed solution

[Andrew Haley]

On 17/12/15 01:41, David Wohlferd wrote:
> On the contrary, I would be surprised to learn that there are ANY 
> compilers (other than clang) that support gcc's extended asm format.  

Prepare to be surprised: Sun Studio compilers seem to support it
just fine.

Andrew.