Re: Bin Cheng appointed Loop Optimizer co-maintainer

[Bin.Cheng]

On Mon, May 21, 2018 at 6:20 PM, David Edelsohn  wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Bin Cheng as Loop Optimizer co-maintainer.
>
> Please join me in congratulating Bin on his new role.
> Bin, please update your listing in the MAINTAINERS file.

Thanks very much for the trust in me.  Patch applied as r260500.

Thanks,
bin
>
> Happy hacking!
> David
>

Re: How do I stop gcc from loading data into registers when that's not needed?

[Richard Biener]

On Tue, May 22, 2018 at 2:19 AM Paul Koning  wrote:



> > On May 18, 2018, at 2:07 PM, Richard Biener 
wrote:
> >
> > On May 18, 2018 8:03:05 PM GMT+02:00, Paul Koning <
paulkon...@comcast.net> wrote:
> >> Gents,
> >>
> >> In some targets, like pdp11 and vax, most instructions can reference
> >> data in memory directly.
> >>
> >> So when I have "if (x < y) ..." I would expect something like this:
> >>
> >>  cmpw  x, y
> >>  bgeq  1f
> >>  ...
> >>
> >> What I actually see, with -O2 and/or -Os, is:
> >>
> >>  movw  x, r0
> >>  movw  y, r1
> >>  cmpw  r0, r1
> >>  bgeq  1f
> >>  ...
> >>
> >> which is both longer and slower.  I can't tell why this happens, or how
> >> to stop it.  The machine description has "general_operand" so it
> >> doesn't seem to be the place that forces things into registers.
> >
> > I would expect combine to merge the load and arithmetic and thus it is
eventually the target costing that makes that not succeed.
> >
> > Richard.

> Thanks Richard.  I am not having a whole lot of luck figuring out where
precisely I need to adjust or how to make the adjustment.  I'm doing the
adjusting on the pdp11 port right now.  That has a TARGET_RTX_COSTS hook
which looks fairly plausible.  It doesn't currently have a
TARGET_MEMORY_MOVE_COST, or TARGET_ADDRESS_COST, or TARGET_INSN_COST.  It
is likely that I need some or all of those to get this working better?  If
yes, any hints you can offer where to start?

Sorry, I'm not very familiar with this area of GCC either.  Did you confirm
that combine at least tries to merge the memory ops into the instruction?
Maybe it is only RA / reload that will try.  You can look at how it works
for x86, for example whether there's already memory ops in the stmts
during RTL expansion which can happen I think when the load has a single
use (and if that works for pdp11).

Richard.

>  paul

Re: Generating gimple assign stmt that changes sign

[Richard Biener]

On Tue, May 22, 2018 at 12:51 AM Kugan Vivekanandarajah <
kugan.vivekanandara...@linaro.org> wrote:

> Hi,

> I am looking to introduce ABSU_EXPR and that would create:

> unsigned short res = ABSU_EXPR (short);

> Note that the argument is signed and result is unsigned. As per the
> review, I have a match.pd entry to generate this as:
> (simplify (abs (convert @0))
>   (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0)))
>(convert (absu @0

This would convert abs ((int) unsigned_int_var) to (int) absu
(unsigned_int_var)
which is bogus given it results in -1 for abs (-1).  You want to restrict
this to
sign-extensions, thus !TYPE_UNSIGNED (TREE_TYPE (@0)) && !TYPE_UNSIGNED
(type)
&& element_precision (type) < element_precision (TREE_TYPE (@0))

> Now when gimplifying the converted tree, how do we tell that ABSU_EXPR
> will take a signed arg and return unsigned. I will have other match.pd
> entries so this will be generated while in gimple.passes too. Should I
> add new functions in gimple.[h|c] for this.

As Marc says you can use sth like

  (with { tree utype = unsigned_type_for (TREE_TYPE (@0)); }
  (convert (absu:utype @0))

or you can hack genmatch to recognize ABSU_EXPR.

> Is there any examples I can refer to. Conversion expressions seems to
> be the only place where sign can change in gimple assignment but they
> are very specific.

> Thanks,
> Kugan

[PING][PATCH] gdb/x86: Fix `-Wstrict-overflow' build error in `i387_collect_xsave'

[Maciej W. Rozycki]

On Tue, 15 May 2018, Maciej W. Rozycki wrote:

>   gdb/
>   * i387-tdep.c (i387_collect_xsave): Make `i' unsigned.

 Ping for: .

  Maciej

Re: [PING][PATCH] gdb/x86: Fix `-Wstrict-overflow' build error in `i387_collect_xsave'

[Pedro Alves]

On 05/22/2018 12:14 PM, Maciej W. Rozycki wrote:
> On Tue, 15 May 2018, Maciej W. Rozycki wrote:
> 
>>  gdb/
>>  * i387-tdep.c (i387_collect_xsave): Make `i' unsigned.
> 
>  Ping for: .

OK.

Thanks,
Pedro Alves

Re: gcc-6-branch test failures: g++ c-c++-common/asan/pr59063-2.c

[Jason Vas Dias]

This problem turned out to be because the objects in
libasan.a of gcc-6-branch are built with -fPIC / -DPIC :
if 'PIC' is defined, the code in asan_linux.c is
assuming it has been dynamically loaded , and so
does not allow libasan.so NOT to be the first
required dynamic library. But adding '-lasan'
is a bad idea, since then the
   dlsym(RTLD_NEXT,"sigaction")
actually resolves to __interception::sigaction
which ends up calling itself until stack is exhausted.

For some reason (which I am trying to figure out, but
which is not obvious) the gcc-7-branch libasan build
does build all the libasan.a objects without -fPIC -DPIC
correctly, and so does not have this problem.

It looks like use of 'static-libasan' in GCC 6 builds
is thoroughly disabled and broken because of libasan.a
objects ARE built with -fPIC / -DPIC .

Maybe I should raise a bug about this?

Thanks & Regards,
Jason

DF mangling

[Segher Boessenkool]

Hi!

The Itanium C++ ABI defines
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin
DF_ as the mangling for the  bit IEEE binary float type,
i.e. _Float.

But the libiberty unwinders decode DF as fixed point type, see
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libiberty/cp-demangle.c;h=3f2a097e7f2075e5750e40a31ce46589d4ab83d5;hb=HEAD#l2659

This conflicts.  How are we going to resolve it?


Segher

Re: DF mangling

[Joseph Myers]

On Tue, 22 May 2018, Segher Boessenkool wrote:

> Hi!
> 
> The Itanium C++ ABI defines
> https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin
> DF_ as the mangling for the  bit IEEE binary float type,
> i.e. _Float.
> 
> But the libiberty unwinders decode DF as fixed point type, see
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libiberty/cp-demangle.c;h=3f2a097e7f2075e5750e40a31ce46589d4ab83d5;hb=HEAD#l2659
> 
> This conflicts.  How are we going to resolve it?

I don't think there's any conflict between the mangling DF_ for 
_FloatN, and DF[ijstlmxy][sn] for fixed point.  If DF is 
followed by a number, the following character is '_' for _FloatN and the 
code for an integer type for fixed point.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: DF mangling

[Segher Boessenkool]

On Tue, May 22, 2018 at 05:40:49PM +, Joseph Myers wrote:
> On Tue, 22 May 2018, Segher Boessenkool wrote:
> 
> > Hi!
> > 
> > The Itanium C++ ABI defines
> > https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin
> > DF_ as the mangling for the  bit IEEE binary float type,
> > i.e. _Float.
> > 
> > But the libiberty unwinders decode DF as fixed point type, see
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libiberty/cp-demangle.c;h=3f2a097e7f2075e5750e40a31ce46589d4ab83d5;hb=HEAD#l2659
> > 
> > This conflicts.  How are we going to resolve it?
> 
> I don't think there's any conflict between the mangling DF_ for 
> _FloatN, and DF[ijstlmxy][sn] for fixed point.  If DF is 
> followed by a number, the following character is '_' for _FloatN and the 
> code for an integer type for fixed point.

Ah!  Sneaky.  Yes that will work; I'll make a patch.


Segher

Re: How do I stop gcc from loading data into registers when that's not needed?

[Segher Boessenkool]

On Tue, May 22, 2018 at 10:49:35AM +0200, Richard Biener wrote:
> On Tue, May 22, 2018 at 2:19 AM Paul Koning  wrote:
> > > On May 18, 2018, at 2:07 PM, Richard Biener 
> wrote:
> > > On May 18, 2018 8:03:05 PM GMT+02:00, Paul Koning <
> paulkon...@comcast.net> wrote:
> > >> In some targets, like pdp11 and vax, most instructions can reference
> > >> data in memory directly.
> > >>
> > >> So when I have "if (x < y) ..." I would expect something like this:
> > >>
> > >>  cmpw  x, y
> > >>  bgeq  1f
> > >>  ...
> > >>
> > >> What I actually see, with -O2 and/or -Os, is:
> > >>
> > >>  movw  x, r0
> > >>  movw  y, r1
> > >>  cmpw  r0, r1
> > >>  bgeq  1f
> > >>  ...
> > >>
> > >> which is both longer and slower.  I can't tell why this happens, or how
> > >> to stop it.  The machine description has "general_operand" so it
> > >> doesn't seem to be the place that forces things into registers.
> > >
> > > I would expect combine to merge the load and arithmetic and thus it is
> eventually the target costing that makes that not succeed.
> 
> > Thanks Richard.  I am not having a whole lot of luck figuring out where
> > precisely I need to adjust or how to make the adjustment.  I'm doing the
> > adjusting on the pdp11 port right now.  That has a TARGET_RTX_COSTS hook
> > which looks fairly plausible.  It doesn't currently have a
> > TARGET_MEMORY_MOVE_COST, or TARGET_ADDRESS_COST, or TARGET_INSN_COST.  It
> > is likely that I need some or all of those to get this working better?  If
> > yes, any hints you can offer where to start?

-fdump-rtl-combine-all (or just -da or -dap), and then look at the dump
file.  Does combine try this combination?  If so, it will tell you what
the resulting costs are.  If not, why does it not try it?

> Sorry, I'm not very familiar with this area of GCC either.  Did you confirm
> that combine at least tries to merge the memory ops into the instruction?

It should, it's a simple reg dependency.  In many cases it will even do
it if it is not single-use (via a 3->2 combination).


Segher

Re: Generating gimple assign stmt that changes sign

[Jeff Law]

On 05/21/2018 05:25 PM, Kugan Vivekanandarajah wrote:
> Hi Jeff,
> 
> Thanks for the prompt reply.
> 
> On 22 May 2018 at 09:10, Jeff Law  wrote:
>> On 05/21/2018 04:50 PM, Kugan Vivekanandarajah wrote:
>>> Hi,
>>>
>>> I am looking to introduce ABSU_EXPR and that would create:
>>>
>>> unsigned short res = ABSU_EXPR (short);
>>>
>>> Note that the argument is signed and result is unsigned. As per the
>>> review, I have a match.pd entry to generate this as:
>>> (simplify (abs (convert @0))
>>>  (if (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0)))
>>>   (convert (absu @0
>>>
>>>
>>> Now when gimplifying the converted tree, how do we tell that ABSU_EXPR
>>> will take a signed arg and return unsigned. I will have other match.pd
>>> entries so this will be generated while in gimple.passes too. Should I
>>> add new functions in gimple.[h|c] for this.
>>>
>>> Is there any examples I can refer to. Conversion expressions seems to
>>> be the only place where sign can change in gimple assignment but they
>>> are very specific.
>> What's the value in representing ABSU vs a standard ABS followed by a
>> conversion?
> 
> It is based on PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64946.
> Specifically, comment 13.
Thanks.  I was wondering if it was supposed to allow you to exploit
hardware capability in the vectorizer better.
> 
>>
>> You'll certainly want to do verification of the type signedness in the
>> gimple verifier.
> I am doing it and it is failing now.
Yea, you're going to have to dig into those.

There may also be some propagations you want to disable or enable given
the semantics you're defining for ABSU.


Jeff

Re: How do I stop gcc from loading data into registers when that's not needed?

[Paul Koning]

> On May 22, 2018, at 3:26 PM, Segher Boessenkool  
> wrote:
> 
> 
> -fdump-rtl-combine-all (or just -da or -dap), and then look at the dump
> file.  Does combine try this combination?  If so, it will tell you what
> the resulting costs are.  If not, why does it not try it?
> 
>> Sorry, I'm not very familiar with this area of GCC either.  Did you confirm
>> that combine at least tries to merge the memory ops into the instruction?
> 
> It should, it's a simple reg dependency.  In many cases it will even do
> it if it is not single-use (via a 3->2 combination).

I examined what gcc does with two simple functions:

void c2(void)
{
if (x < y)
z = 1;
else if (x != y)
z = 42;
else
z = 9;
}

void c3(void)
{
if (x < y)
z = 1;
else
z = 9;
}

Two things popped out.

1. The original RTL (from the expand phase) has a memory->register move for x 
and y in c2, but it doesn't for c3 (it simply generates a memory/memory compare 
there).  What triggers the different choice in that phase?

2. The reported costs for the various insns are
r22:HI=['x']6
cmp(r22:HI,r23:HI)  4
cmp(['x'],['y'])16
   so the added cost for the memory argument in the cmp is 6 -- the same as the 
whole cost for the mov.  That certainly explains the behavior.  It isn't what I 
want it to be.  Which target hook(s) are involved in these numbers?  I don't 
see them in my rtx_costs hook.

paul

Suse Linux ( s390x-linux-gnu-gcc )

[Sreekanth G]

Hi, 

I have install  GoLang  on Suse Linux on IBM cloud.
go version is go1.10.2 linux/s390x

When running the go build command it’s showing error. see below ,

linux1@sfhyperledger:~/go1.X/src/syndicateLoans> go build
# github.com/hyperledger/fabric/vendor/github.com/miekg/pkcs11 

exec: "s390x-linux-gnu-gcc": executable file not found in $PATH

I got stuck here from 2 days.. I don’t know how will proceed. Could help from 
this error ?



Thanks & regards,
Sreekanth G