Re: GCC Buildbot Update

[Paulo Matos]

On 15/12/17 10:21, Christophe Lyon wrote:
> On 15 December 2017 at 10:19, Paulo Matos  wrote:
>>
>>
>> On 14/12/17 21:32, Christophe Lyon wrote:
>>> Great, I thought the CF machines were reserved for developpers.
>>> Good news you could add builders on them.
>>>
>>
>> Oh. I have seen similar things happening on CF machines so I thought it
>> was not a problem. I have never specifically asked for permission.
>>
 pmatos@gcc115:~/gcc-8-20171203_BUILD$ as -march=armv8.1-a
 Assembler messages:
 Error: unknown architecture `armv8.1-a'

 Error: unrecognized option -march=armv8.1-a

 However, if I run the a compiler build manually with just:

 $ configure --disable-multilib
 $ nice -n 19 make -j4 all

 This compiles just fine. So I am at the moment attempting to investigate
 what might cause the difference between what buildbot does and what I do
 through ssh.

>>> I suspect you are hitting a bug introduced recently, and fixed by:
>>> https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00434.html
>>>
>>
>> Wow, that's really useful. Thanks for letting me know.
>>
> And the patch was committed last night (r255659), so maybe your builds now 
> work?
> 

On some machines, in incremental builds I still seeing this:
Assembler messages:
Error: unknown architectural extension `lse'
Error: unrecognized option -march=armv8-a+lse
make[4]: *** [load_1_1_.lo] Error 1
make[4]: *** Waiting for unfinished jobs

Looks related... the only strange thing happening is that this doesn't
happen in full builds.

-- 
Paulo Matos

Re: Load and parse RTL from textual dump files

[HEBBAL Yacine]

Hi Kyrill,
Thank you for your response.
I looked at GCC RTL tests and I saw that the RTL format in these files is
embedded in C functions and slightly different from the one in dump files
generated with -fdump-rtl-expand option.
So for large scale analysis, do you think that writing a GCC plugin is a
reliable solution for my use case ? thanks

Yacine

2017-12-18 13:31 GMT+01:00 Kyrill Tkachov :

> Hi,
>
>
> On 18/12/17 10:30, HEBBAL Yacine wrote:
>
>> Hello,
>> In one of my projects, I need to determine automatically what are the
>> names
>> and types of data fields manipulated by functions in binary code of a
>> given
>> program (e.g. Linux kernel).
>> I found that RTL dumps contains most of information I need in a form very
>> close to the one of the binary code.
>> For this end, I need to parse generated RTL expressions in order to
>> extract
>> operands properties.
>> Is it possible to load and parse RTL expressions from textual dump files
>> using existing code in GCC ? Thanks
>>
>
> Since version 7 GCC does contain functionality to parse RTL input.
> This is mostly used for writing more targeted unit tests for the RTL
> passes.
> Have a look at https://gcc.gnu.org/onlinedocs/gccint/RTL-Tests.html or
> grep for "__RTL"
> in the gcc testsuite (gcc/testsuite in the source tree) to see examples of
> how it's used.
>
> Not sure how useful it will be for large-scale analysis of source code
> though.
> You may want to write/use a GCC plugin for that.
>
> Kyrill
>
> P.S. This list is used for discussions about the development of GCC itself.
> For help using GCC please use the gcc-help list in the future.
>

Re: GCC Buildbot Update

[Christophe Lyon]

On 20 December 2017 at 09:31, Paulo Matos  wrote:
>
>
> On 15/12/17 10:21, Christophe Lyon wrote:
>> On 15 December 2017 at 10:19, Paulo Matos  wrote:
>>>
>>>
>>> On 14/12/17 21:32, Christophe Lyon wrote:
 Great, I thought the CF machines were reserved for developpers.
 Good news you could add builders on them.

>>>
>>> Oh. I have seen similar things happening on CF machines so I thought it
>>> was not a problem. I have never specifically asked for permission.
>>>
> pmatos@gcc115:~/gcc-8-20171203_BUILD$ as -march=armv8.1-a
> Assembler messages:
> Error: unknown architecture `armv8.1-a'
>
> Error: unrecognized option -march=armv8.1-a
>
> However, if I run the a compiler build manually with just:
>
> $ configure --disable-multilib
> $ nice -n 19 make -j4 all
>
> This compiles just fine. So I am at the moment attempting to investigate
> what might cause the difference between what buildbot does and what I do
> through ssh.
>
 I suspect you are hitting a bug introduced recently, and fixed by:
 https://gcc.gnu.org/ml/gcc-patches/2017-12/msg00434.html

>>>
>>> Wow, that's really useful. Thanks for letting me know.
>>>
>> And the patch was committed last night (r255659), so maybe your builds now 
>> work?
>>
>
> On some machines, in incremental builds I still seeing this:
> Assembler messages:
> Error: unknown architectural extension `lse'
> Error: unrecognized option -march=armv8-a+lse
> make[4]: *** [load_1_1_.lo] Error 1
> make[4]: *** Waiting for unfinished jobs
>
> Looks related... the only strange thing happening is that this doesn't
> happen in full builds.
>

The recent fix changed the Makefile and configure script in libatomic.
I guess that if your incremental builds does not run configure, it's
still using old Makefiles, and old options.


> --
> Paulo Matos

Re: GCC Buildbot Update

[Paulo Matos]

On 20/12/17 10:51, Christophe Lyon wrote:
> 
> The recent fix changed the Makefile and configure script in libatomic.
> I guess that if your incremental builds does not run configure, it's
> still using old Makefiles, and old options.
> 
> 
You're right. I guess incremental builds should always call configure,
just in case.

Thanks,
-- 
Paulo Matos

Re: GCC Buildbot Update

[Christophe Lyon]

On 20 December 2017 at 11:02, Paulo Matos  wrote:
>
>
> On 20/12/17 10:51, Christophe Lyon wrote:
>>
>> The recent fix changed the Makefile and configure script in libatomic.
>> I guess that if your incremental builds does not run configure, it's
>> still using old Makefiles, and old options.
>>
>>
> You're right. I guess incremental builds should always call configure,
> just in case.
>

Maybe, but this does not always work. Sometimes, I have to rm -rf $builddir


> Thanks,
> --
> Paulo Matos

Re: GCC Buildbot Update

[James Greenhalgh]

On Wed, Dec 20, 2017 at 10:02:45AM +, Paulo Matos wrote:
> 
> 
> On 20/12/17 10:51, Christophe Lyon wrote:
> > 
> > The recent fix changed the Makefile and configure script in libatomic.
> > I guess that if your incremental builds does not run configure, it's
> > still using old Makefiles, and old options.
> > 
> > 
> You're right. I guess incremental builds should always call configure,
> just in case.

For my personal bisect scripts I try an incremental build, with a
full rebuild as a fallback on failure.

That gives me the benefits of an incremental build most of the time (I
don't have stats on how often) with an automated approach to keeping things
going where there are issues.

Note that there are rare cases where depencies are missed in the toolchain
and an incremental build will give you a toolchain with undefined
behaviour, as one compilation unit takes a new definition of a
struct/interface and the other sits on an outdated compile from the
previous build.

I don't have a good way to detect these.

Thanks,
James

Re: GCC Buildbot Update

[Paulo Matos]

On 20/12/17 12:48, James Greenhalgh wrote:
> On Wed, Dec 20, 2017 at 10:02:45AM +, Paulo Matos wrote:
>>
>>
>> On 20/12/17 10:51, Christophe Lyon wrote:
>>>
>>> The recent fix changed the Makefile and configure script in libatomic.
>>> I guess that if your incremental builds does not run configure, it's
>>> still using old Makefiles, and old options.
>>>
>>>
>> You're right. I guess incremental builds should always call configure,
>> just in case.
> 
> For my personal bisect scripts I try an incremental build, with a
> full rebuild as a fallback on failure.
> 
> That gives me the benefits of an incremental build most of the time (I
> don't have stats on how often) with an automated approach to keeping things
> going where there are issues.
> 
> Note that there are rare cases where depencies are missed in the toolchain
> and an incremental build will give you a toolchain with undefined
> behaviour, as one compilation unit takes a new definition of a
> struct/interface and the other sits on an outdated compile from the
> previous build.
> 
> I don't have a good way to detect these.
> 

That's definitely a shortcoming of incremental builds. Unfortunately we
cannot cope with full builds for each commit (even for incremental
builds we'll need an alternative soon). So I will implement the same
strategy of full build if incremental fails, I think.

With respect with regards to incremental builds with undefined behaviour
that probably means that dependencies are incorrectly calculated. It
would be great to sort these out. If we could detect that there are
issues with the incremental build we could then try to understand which
dependencies were not properly calculated. Just a guess, however
implementing this might take awhile and would obviously need a lot more
resources than we have available now.

-- 
Paulo Matos

typeid name of non-throwing function type

[Stephan Bergmann]

I see with any recent GCC (when targeting the Itanium C++ ABI),


$ cat test.cc
#include 
#include 
void f() noexcept;
int main() { std::cout << typeid(f).name() << '\n'; }

$ g++ -std=c++17 test.cc
$ ./a.out
FvvE


that the function type's mangling doesn't contain the noexcept specifier 
(in which case it would be "DoFvvE").


Is that a deliberate decision in GCC, or does it just happen by accident 
(as for function pointer types, the Itanium ABI encodes noexcept 
specifiers at the __pointer_type_info, not at the underlying 
__function_type_info)?


I'm asking in the context of Clang patch 
 "No -fsanitize=function warning when 
calling noexcept function through non-noexcept pointer in C++17".  Clang 
happens to produce type_info for the noexcept-annotated function type 
(with "DoFvvE" name) in the above example, and not doing so (and instead 
behaving like GCC does) would be one way to solve the issue I want to 
fix with that patch.

Re: Register Allocation Graph Coloring algorithm and Others

[Jakob Stoklund Olesen]

> On Dec 18, 2017, at 19:03, Leslie Zhai  wrote:

Hi Leslie,

As others have pointed out, the notion that register allocation is isomorphic 
to graph coloring is poppycock. There are other important aspects, in 
particular the placement of spill/fill/copy instructions. The importance of 
graph coloring relative to spill code placement depends on how many registers 
you have available. If you are generating code for 32-bit x86 which has only 
6-7 general purpose registers, you will have so much spill code and short live 
ranges that graph coloring doesn’t matter much at all. On the other hand, if 
you have 32 registers like Chaitin did, you have much less spilling in typical 
code, and the graph coloring aspect becomes important.

Early compilers would keep each local variable in a stack slot, and the 
register allocation optimization would literally allocate a whole local 
variable to a register. The C “register” keyword makes sense in that context. 
Later improvements like copy coalescing and live range splitting meant that 
multiple local variables could use the same register and a variable could live 
in different places at different times. It is sometimes useful to take this 
development to its logical extreme and look at register allocation as a caching 
problem: The register allocator’s job is to make sure that values are available 
to the instructions the need them, using the registers as a cache to get the 
values there in the most efficient way possible.

Guo, J., Garzarán, M. J., & Padua, D. (2004). The Power of Belady’s Algorithm 
in Register Allocation for Long Basic Blocks. In Languages and Compilers for 
Parallel Computing (Vol. 2958, pp. 374–389). Berlin, Heidelberg: Springer 
Berlin Heidelberg. http://doi.org/10.1007/978-3-540-24644-2_24

Braun, M., & Hack, S. (2009). Register spilling and live-range splitting for 
SSA-form programs. International Conference on Compiler Construction.

When you look at register allocation that way, the graph coloring aspect almost 
disappears. The optimum approach is probably somewhere in the middle.

A third important aspect is register constraints on individual instructions. 
Sometimes you almost need a little constraint solver just to figure out a valid 
register assignment for a single instruction. Preston Briggs dealt with this in 
his thesis, but it hasn’t gotten as much attention as graph coloring since.

Pereira, F. Q., & Palsberg, J. (2008). Register allocation by puzzle solving.

Regards,
/jakob

gcc-6-20171220 is now available

[gccadmin]

Snapshot gcc-6-20171220 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20171220/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 255904

You'll find:

 gcc-6-20171220.tar.xzComplete GCC

  SHA256=d1c14479748be5fb5c66e7d757e4e4875183751024c77c36d0d17d5e51fff879
  SHA1=9ab77d06ed9374f556fbcea3fd24eab2d0b7c890

Diffs from 6-20171213 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Register Allocation Graph Coloring algorithm and Others

[Leslie Zhai]

Hi Jakob,

Thanks for your kind response!

My usecase is for AVR and RISCV targets, and I just want to learn and 
practice HEA in RA, thanks for your sharing.



在 2017年12月21日 01:25, Jakob Stoklund Olesen 写道:


On Dec 18, 2017, at 19:03, Leslie Zhai > wrote:


Hi Leslie,

As others have pointed out, the notion that register allocation is 
isomorphic to graph coloring is poppycock. There are other important 
aspects, in particular the placement of spill/fill/copy instructions. 
The importance of graph coloring relative to spill code placement 
depends on how many registers you have available. If you are 
generating code for 32-bit x86 which has only 6-7 general purpose 
registers, you will have so much spill code and short live ranges that 
graph coloring doesn’t matter much at all. On the other hand, if you 
have 32 registers like Chaitin did, you have much less spilling in 
typical code, and the graph coloring aspect becomes important.


Early compilers would keep each local variable in a stack slot, and 
the register allocation optimization would literally allocate a whole 
local variable to a register. The C “register” keyword makes sense in 
that context. Later improvements like copy coalescing and live range 
splitting meant that multiple local variables could use the same 
register and a variable could live in different places at different 
times. It is sometimes useful to take this development to its logical 
extreme and look at register allocation as a caching problem: The 
register allocator’s job is to make sure that values are available to 
the instructions the need them, using the registers as a cache to get 
the values there in the most efficient way possible.


Guo, J., Garzarán, M. J., & Padua, D. (2004). The Power of
Belady’s Algorithm in Register Allocation for Long Basic Blocks.
In Languages and Compilers for Parallel Computing (Vol. 2958, pp.
374–389). Berlin, Heidelberg: Springer Berlin Heidelberg.
http://doi.org/10.1007/978-3-540-24644-2_24

Braun, M., & Hack, S. (2009). Register spilling and live-range
splitting for SSA-form programs. International Conference on
Compiler Construction.


When you look at register allocation that way, the graph coloring 
aspect almost disappears. The optimum approach is probably somewhere 
in the middle.


A third important aspect is register constraints on individual 
instructions. Sometimes you almost need a little constraint solver 
just to figure out a valid register assignment for a single 
instruction. Preston Briggs dealt with this in his thesis, but it 
hasn’t gotten as much attention as graph coloring since.


Pereira, F. Q., & Palsberg, J. (2008). Register allocation by
puzzle solving.


Regards,
/jakob



--
Regards,
Leslie Zhai - https://reviews.llvm.org/p/xiangzhai/

Timezone updates requested

[Eric S. Raymond]

If you have commits in the GCC repo, pleae send me your preferred IANA
time zone and/or place of residence *by private reply* - no need to
flood the list.

This is so committer *and author* entries for the converted repo will
get the timezone offset correct for their location and the UTC time
Subversion stored for the commit.  The end goal is to make Git's
local-time displays accurate.

Note that reposurgeon mines /usr/share/zoneinfo/zone.tab to produce a
default mapping between top-level domains of countries and timezones;
this handles, in particular, addresses in .gb, .de, .fi, and .cz
exactly. If you are in a country TLD of a single-timezone country, you
can ignore this request.  However, beware that some small countries
have overseas dominions - your timezone may not be as singular as you
think, it's safest to report in and nail down your zone.

Those of you using addresses in the functional domains, or from large
multiple-zone countries (especially the U.S. and Russia), should
*definitely* report in with a timezone.  Otherwise your attributed
times could be up to 4 hours off (11 in Russia!).

In an earlier version of this request, I enclosed a copy of the current map
I've omitted it this time to see if that avoids triggering the list spam
filters.  There will be followup email about this.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

"As to the species of exercise, I advise the gun. While this gives [only]
moderate exercise to the body, it gives boldness, enterprise, and independence
to the mind.  Games played with the ball and others of that nature, are too
violent for the body and stamp no character on the mind. Let your gun,
therefore, be the constant companion to your walks."
-- Thomas Jefferson, writing to his teenaged nephew.

Re: typeid name of non-throwing function type

[Stephan Bergmann]

On 12/20/2017 03:48 PM, Stephan Bergmann wrote:

I see with any recent GCC (when targeting the Itanium C++ ABI),


$ cat test.cc
#include 
#include 
void f() noexcept;
int main() { std::cout << typeid(f).name() << '\n'; }

$ g++ -std=c++17 test.cc
$ ./a.out
FvvE


that the function type's mangling doesn't contain the noexcept specifier 
(in which case it would be "DoFvvE").


Is that a deliberate decision in GCC, or does it just happen by accident 
(as for function pointer types, the Itanium ABI encodes noexcept 
specifiers at the __pointer_type_info, not at the underlying 
__function_type_info)?


Thinking a bit more about it, I think that's rather a bug in GCC, right?


~ cat test72.cc
#include 
#include 
void f1();
void f2() noexcept;
int main() { std::cout << (typeid(f1) == typeid(f2)) << '\n'; }

~ g++ -std=c++17 test72.cc
~ ./a.out
1


should print "0" instead of "1" (like the version does that compares

  (typeid(&f1) == typeid(&f2))

instead).