Re: Bootstrap problem with genatautomata and sysroot
On Mon, 2018-11-26 at 22:47 +0100, Andreas Schwab wrote: > External Email > > On Nov 26 2018, Steve Ellcey wrote: > > > I looked through the patches for the last couple of weeks to see if > > I could identify > > what changed here but I haven't found anything. Maybe it was > > something in > > glibc that changed. > > Most likely it only worked by accident so far. Last week the first > GLIBC_2.29 symbol has been added to libm. > > Andreas. Yup, I backed off those glibc changes and I could build, so that seems to be the problem. I guess if I want to build a complete toolchain with bootstrap I will need to update the libm that is in /lib. Steve Ellcey
Re: GCC Common-Function-Attributes/const
On 11/26/18 1:30 PM, cmdLP #CODE wrote:
Dear GCC-developer team,
The specification of the const-attribute is a bit ambiguous, it does not
fully specify which global variables are allowed to be read from. Obviously
constant global compile-time initialized variables can be accessed without
problem. But what about run time initialized variables like a lookup table
or the initialization of an api? Does GCC may invoke the function before
the initialization of the lookup table/api; or is it guaranteed, that the
function is only called in places, where it would be called without the
attribute. I also propose some additional attributes to let the programmer
clarify his/her intentions.
The purpose of the const attribute is to let GCC assume that
invocations of a function it's on with the same argument values
yield the same result no matter when they are made. Any function
that satisfies this constraint can be declared with the attribute,
whether it depends on values of global objects or not, const or
not, just as long as their values do not change between any two
invocations of the function in a way that would affect its result.
It should even be possible to define a const function to return
the value of non-constant dynamically initialized data. For
instance:
__attribute__ ((const)) int prime (int i)
{
static int primes[N];
if (!primes[0])
// fill primes with prime numbers
return primes[i];
}
This is a valid const function because its result depends only
on the value of its argument.
The documentation for the attribute is being improved as we speak
in response to PR79738. I expect it to take a few more tweaks
before we're completely happy with it.
Here are some code snippets, how GCC might change the generated code,
according to the documentation.
In my opinion, each generated output should be assigned to a distinct
attribute.
*Function declarations:*
*void init_values();*
*int read_value(int index) [[gnu::const]];*
*void use_value(int value);*
*Problematic code:*
*int main(int argc, char** argv) {*
*init_values();*
*for(int i=1; i < argc; ++i) {*
*int value = read_value(0); // constant*
*use_value(value, argv[i]);*
*}*
*}*
Here are some possible outputs, which are possible, because of the
ambiguity of the documentation. The attribute next to "Transformation" is
the proposed new attribute names, which could lead to the transformatio
(when [[gnu::const]] is replaced with it).
*Transformation [[gnu::const, gnu::is_simple]]*
*int read_value__with_0;*
*int main(int argc, char**) {*
*read_value__with_0 = read_value(0);*
*init_values();*
*for(int i=1; i < argc; ++i) {*
*use_value(read_value__with_0, argv[i]);*
*}*
*}*
The code is called at some undefined point, maybe at the start of main,
even if it is never used, because the compiler assumes, that the function
simply reads from constant memory/does a simple calculation. In the case of
the example, it is not what the programmer intended.
Right. This definition makes read_value() unsuitable for attribute
const.
I don't have a sense of how much software would benefit from
the attributes proposed below.
Martin
*Transformation [[gnu::const]]*
*int read_value__with_0;*
*int main(int argc, char** argv) {*
*if(argc > 1) read_value__with_0 = read_value(0);*
*init_values();*
*for(int i=1; i < argc; ++i) {*
*use_value(read_value__with_0, argv[i]);*
*}*
*}*
This is almost the same to the previous version, but it only calls the
function, if the result is used.
Both attributes (the time when it is called is undefined) can also result
in the following code where the attributes give a stronger guarantee, when
it is called (the first time). The following works semantically as the
programmer intended/when the attributes were ignored.
*Transformation** [[gnu::const(init_values()), gnu::is_simple]]*
*int read_value__with_0;*
*int main() {*
*init_values();*
*read_value__with_0 = read_value(0);*
*for(int i=1; i < 100; ++i) {*
*use_value(read_value__with_0, argv[i]);*
*}*
*}*
*Transformation **[[gnu::const(init_values())]]*
*int read_value__with_0;*
*int main() {*
*init_values();*
*if(argc > 1) read_value__with_0 = read_value(0);*
*for(int i=1; i < 100; ++i) {*
*use_value(read_value__with_0, argv[i]);*
*}*
*}*
The function is guaranteed to never use the returned values again, when the
given expression in the attribute parameter list is called, so the compiler
interprets the given function as an initializing function.
*PROPOSED ATTRIBUTES*
*[[gnu::is_simple]]*
In connection to the [[gnu::const]] attribute this attribute implies, that
the function might be called when the result is not used. Eg. when the
function is called in a conditional branch, the call can be extracted from
the branch and can be called outside. This should be applied to very simple
functions.
*[[gnu::const]]*
The meaning is kept as bef
Re: question about attribute aligned for functions
On 11/23/18 12:31 PM, Martin Sebor wrote: > GCC currently accepts the declaration of f0 below but ignores > the attribute. On aarch64 (and I presume on other targets with > a default function alignment greater than 1), GCC rejects f1 > with an error, even though it accepts -falign-functions=1 > without as much as a warning. > > Clang, on the other hand, rejects f0 with a hard error because > the alignment is not a power of two, but accepts f1 and appears > to honor the attribute. It also accepts -falign-functions=1. > > I think diagnosing f0 with a warning is helpful because an explicit > zero alignment is most likely a mistake (especially when it comes > from a macro or some computation). > > But I don't see a good reason to reject a program that specifies > a smaller alignment for a function when the default (or minimum) > alignment is greater. A smaller alignment is trivially satisfied > by a greater alignment so either accepting it or dropping it seems > preferable to failing with an error (either could be with or without > a warning). > > __attribute__ ((aligned (0))) void f0 (void); // accepted, ignored > __attribute__ ((aligned (1))) void f1 (void); // aarch64 error > __attribute__ ((aligned (4))) void f4 (void); // okay > > Does anyone know why GCC rejects the program, or can anyone think > of a reason why GCC should not behave as suggested above? Note we have targets that support single byte opcodes and do not have any requirements for functions starting on any boundary. mn103 comes to mind. However, the attribute can't be used to decrease a function's alignment, so values of 0 or 1 are in practice totally uninteresting and one could make an argument to warn for them. Whether or not to warn in general if the alignment attribute is smaller than the default may be subject to debate. I guess it depends on the general intent that we'd find in real world codes. jeff
Re: Bootstrap problem with genatautomata and sysroot
On Nov 26 2018, Steve Ellcey wrote: > I looked through the patches for the last couple of weeks to see if I could > identify > what changed here but I haven't found anything. Maybe it was something in > glibc that changed. Most likely it only worked by accident so far. Last week the first GLIBC_2.29 symbol has been added to libm. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
CATALOG
Hello, Our company is importing for US market for this year sales : Please provide us the following … - Catalog - MOQ - Prices - Payment and warranty terms - Delivery time Our business is growing well so we need to grow our number of suppliers/partners. Thank you, Milagros Torres Alexandra Premium Distribution Corp. 130 7 th avenue Suite 218 New York,NY 10011 Tel : 917 476 04 72
Bootstrap problem with genatautomata and sysroot
I am trying to do a bootstrap build of GCC using a newly built glibc in a non standard location on my aarch64 platform (thunderx). This was working up until a week or so ago but now I am running into a problem I haven't seen before: build/genautomata /home/sellcey/test-tot/src/gcc/gcc/common.md /home/sellcey/test-tot/src/gcc/gcc/config/aarch64/aarch64.md \ insn-conditions.md > tmp-automata.c build/genautomata: /lib/aarch64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by build/genautomata) Makefile:2326: recipe for target 's-automata' failed Has anyone else seen this? I am building binutils and an initial GCC into a sysroot location, then I build glibc using that GCC and install it into that sysroot location and finally do a full GCC build with bootstrap. It is the final bootstrap build that fails. If I do a non-bootstrap build of the final GCC then it works. I looked through the patches for the last couple of weeks to see if I could identify what changed here but I haven't found anything. Maybe it was something in glibc that changed. Steve Ellcey sell...@cavium.com
GCC Common-Function-Attributes/const
Dear GCC-developer team,
The specification of the const-attribute is a bit ambiguous, it does not
fully specify which global variables are allowed to be read from. Obviously
constant global compile-time initialized variables can be accessed without
problem. But what about run time initialized variables like a lookup table
or the initialization of an api? Does GCC may invoke the function before
the initialization of the lookup table/api; or is it guaranteed, that the
function is only called in places, where it would be called without the
attribute. I also propose some additional attributes to let the programmer
clarify his/her intentions.
Here are some code snippets, how GCC might change the generated code,
according to the documentation.
In my opinion, each generated output should be assigned to a distinct
attribute.
*Function declarations:*
*void init_values();*
*int read_value(int index) [[gnu::const]];*
*void use_value(int value);*
*Problematic code:*
*int main(int argc, char** argv) {*
*init_values();*
*for(int i=1; i < argc; ++i) {*
*int value = read_value(0); // constant*
*use_value(value, argv[i]);*
*}*
*}*
Here are some possible outputs, which are possible, because of the
ambiguity of the documentation. The attribute next to "Transformation" is
the proposed new attribute names, which could lead to the transformatio
(when [[gnu::const]] is replaced with it).
*Transformation [[gnu::const, gnu::is_simple]]*
*int read_value__with_0;*
*int main(int argc, char**) {*
*read_value__with_0 = read_value(0);*
*init_values();*
*for(int i=1; i < argc; ++i) {*
*use_value(read_value__with_0, argv[i]);*
*}*
*}*
The code is called at some undefined point, maybe at the start of main,
even if it is never used, because the compiler assumes, that the function
simply reads from constant memory/does a simple calculation. In the case of
the example, it is not what the programmer intended.
*Transformation [[gnu::const]]*
*int read_value__with_0;*
*int main(int argc, char** argv) {*
*if(argc > 1) read_value__with_0 = read_value(0);*
*init_values();*
*for(int i=1; i < argc; ++i) {*
*use_value(read_value__with_0, argv[i]);*
*}*
*}*
This is almost the same to the previous version, but it only calls the
function, if the result is used.
Both attributes (the time when it is called is undefined) can also result
in the following code where the attributes give a stronger guarantee, when
it is called (the first time). The following works semantically as the
programmer intended/when the attributes were ignored.
*Transformation** [[gnu::const(init_values()), gnu::is_simple]]*
*int read_value__with_0;*
*int main() {*
*init_values();*
*read_value__with_0 = read_value(0);*
*for(int i=1; i < 100; ++i) {*
*use_value(read_value__with_0, argv[i]);*
*}*
*}*
*Transformation **[[gnu::const(init_values())]]*
*int read_value__with_0;*
*int main() {*
*init_values();*
*if(argc > 1) read_value__with_0 = read_value(0);*
*for(int i=1; i < 100; ++i) {*
*use_value(read_value__with_0, argv[i]);*
*}*
*}*
The function is guaranteed to never use the returned values again, when the
given expression in the attribute parameter list is called, so the compiler
interprets the given function as an initializing function.
*PROPOSED ATTRIBUTES*
*[[gnu::is_simple]]*
In connection to the [[gnu::const]] attribute this attribute implies, that
the function might be called when the result is not used. Eg. when the
function is called in a conditional branch, the call can be extracted from
the branch and can be called outside. This should be applied to very simple
functions.
*[[gnu::const]]*
The meaning is kept as before. But the function can be called any time.
This enshures, that no expression is called inside the function, which has
an observable effect. But when the function is used in a
[[gnu::const(...)]] annotated function each call to this function is
considered an observable effect to the function.
*[[gnu::const([():],...)]]*
This is an extension to the old [[gnu::const]] attribute. But: When some of
the expressions is called, the previous return values are now invalid (the
function depends on the expression). The parameter list specifies variables
used in the expression, which are not known. In the expression, the
parameter of the annotated function itself, member variables/functions and
static variables/functions can be used. If [[gnu::const]] is used on non
static member functions, the function automaticly depends on the
constructor.
Destructors automaticly depend on all non static member functions.
Unclear: A function should never depend on a function/expression, which
calls the annotated function.
*[[gnu::calls([():],...)]]*
This function attributes tells the compiler, that the given expression
might be called inside. This makes older values recieved from
[[gnu::const(...)]] functions (which depend on (parts of) the
Re: GCC 7.4 Status Report (2018-11-22), GCC 7.4 RC1 scheduled for next week
On Mon, 26 Nov 2018, Andreas Krebbel wrote: > On 22.11.18 10:30, Richard Biener wrote: > > > > Status > > == > > > > The GCC 7 branch is open for regression and documentation fixes. > > > > I plan to do a GCC 7.4 release in a few weeks starting with a > > first release candidate at the end of next week, likely Nov. 29th. > > > > Please go through your assigned regression bugs and see which > > fixes can be safely backported to the branch and consider smoke > > testing the state of your favorite target architecture. > > > > > > Quality Data > > > > > > Priority # Change from last report > > --- --- > > P1 > > P2 241 + 77 > > P3 11 - 11 > > P4 177 + 23 > > P5 28 > > --- --- > > Total P1-P3 252 + 66 > > Total 457 + 89 > > > > > > Previous Report > > === > > > > https://gcc.gnu.org/ml/gcc/2018-01/msg00198.html > > > > I would like to commit a backport of: > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01736.html > > Ok? Sure. Richard.
Re: GCC 7.4 Status Report (2018-11-22), GCC 7.4 RC1 scheduled for next week
On 22.11.18 10:30, Richard Biener wrote: > > Status > == > > The GCC 7 branch is open for regression and documentation fixes. > > I plan to do a GCC 7.4 release in a few weeks starting with a > first release candidate at the end of next week, likely Nov. 29th. > > Please go through your assigned regression bugs and see which > fixes can be safely backported to the branch and consider smoke > testing the state of your favorite target architecture. > > > Quality Data > > > Priority # Change from last report > --- --- > P1 > P2 241 + 77 > P3 11 - 11 > P4177 + 23 > P5 28 > --- --- > Total P1-P3 252 + 66 > Total 457 + 89 > > > Previous Report > === > > https://gcc.gnu.org/ml/gcc/2018-01/msg00198.html > I would like to commit a backport of: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01736.html Ok? Andreas
Re: GCC 7.4 Status Report (2018-11-22), GCC 7.4 RC1 scheduled for next week
On Mon, 26 Nov 2018, Iain Sandoe wrote: > > > On 22 Nov 2018, at 09:30, Richard Biener wrote: > > > > > > Status > > == > > > > The GCC 7 branch is open for regression and documentation fixes. > > > > I plan to do a GCC 7.4 release in a few weeks starting with a > > first release candidate at the end of next week, likely Nov. 29th. > > > > Please go through your assigned regression bugs and see which > > fixes can be safely backported to the branch and consider smoke > > testing the state of your favorite target architecture. > > In addition to a small number of Darwin-specific patches, I would like > to back-port the fix for PR81033 which although it is not mentioned as > a regression, is a wrong-code bug on 7.x. The fix was applied to trunk > in August, and to 8.x in Oct, with no reported problems. I checked > Darwin and Linux with the backport over the weekend with no issues > shown. > > OK? Yes. Richard. > Iain > > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
Re: GCC 7.4 Status Report (2018-11-22), GCC 7.4 RC1 scheduled for next week
> On 22 Nov 2018, at 09:30, Richard Biener wrote: > > > Status > == > > The GCC 7 branch is open for regression and documentation fixes. > > I plan to do a GCC 7.4 release in a few weeks starting with a > first release candidate at the end of next week, likely Nov. 29th. > > Please go through your assigned regression bugs and see which > fixes can be safely backported to the branch and consider smoke > testing the state of your favorite target architecture. In addition to a small number of Darwin-specific patches, I would like to back-port the fix for PR81033 which although it is not mentioned as a regression, is a wrong-code bug on 7.x. The fix was applied to trunk in August, and to 8.x in Oct, with no reported problems. I checked Darwin and Linux with the backport over the weekend with no issues shown. OK? Iain
