Re: Question about Gimple FE
On Fri, Apr 3, 2015 at 7:56 PM, Gry Gunvor wrote: > Gcc melt already advertises that it allows access to the internals: > http://gcc-melt.org/ ; I have not tried it yet. > > This is of course not the same as a format that can be exported and > then imported again, but it is attempting to get a similar result. > > (1) Can anyone comment on the quality/usability/performance of the > melt approach? > > (2) Since melt is attempting to get a similar effect, it must be > slicing the gcc internals in a similar way. If melt does what it > says, one could write a gimple exporter in it, though I don't know > about an importer. > > In any case, it seems that half the problems that would be encountered > have already been encountered by melt, so it could be informative to > hear from melt developers/users. Melt is not part of GCC thus it isn't appropriate to use it. Richard. > Gry > > > On Fri, Apr 3, 2015 at 10:05 AM, Richard Biener > wrote: >> On April 3, 2015 5:41:35 PM GMT+02:00, Diego Novillo >> wrote: >>>On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote: On 04/03/2015 09:30 AM, Diego Novillo wrote: > > On Fri, Apr 3, 2015 at 11:10 AM, xue yinsong >>> > wrote: > >> So it’s better not to try to read the exact dump format. >> Could we use a similar but more complete syntax instead? > > > Absolutely. The initial attempt for gimple fe was to use a >>>tuple-based > syntax that is very easy to parse. But that was only chosen because >>>it > simplifies parsing. > > You first need to design a text representation for the IL that >>>allows > conveying all the elements needed to instantiate the in-memory > representation of gimple. Crazy idea, what about something that's modeled after LLVM's >>>representation? >>> >>>I was hesitant to offer this option, but it's certainly a good >>>starting point. The representation encodes CFG, SSA, attributes, >>>declarations and annotations. It has a relatively fixed syntax, which >>>makes it easy to parse. >> >> The other way is to reuse an existing frontend and add extensions so you can >> annotate stuff or use obscure middle end features. Like the C frontend. >> >> Richard. >> >>> >>>Diego. >> >>
Re: Generating gimple code with gimple_build_assign
On Mon, Apr 6, 2015 at 7:29 PM, Steve Ellcey wrote: > I have a simple gimple question. I am trying to introduce an array > into a gimple stream and create a pointer to that array. > > I can create the array with: > > array_type = build_array_type_nelts (char_type_node, 256); > array_var = create_tmp_var (array_type, "spill"); > > I can create a pointer to an array with: > > ptr_type = build_pointer_type (array_type); > ptr_var = create_tmp_var (ptr_type, "spill"); > > But if I try to create an assignment to get the pointer to point to > the array I get a verify_gimple error. > > I have tried: > > stmt = gimple_build_assign (ptr_var, array_var); > and > stmt = gimple_build_assign (ptr_var, ADDR_EXPR, array_var); > > but neither of those work. I also tried making the pointer be a > pointer to char instead of a pointer to array of char but that didn't > seem to work either. Can someone help me with the magic formula to > generate gimple code that causes ptr_var to point to array_var? > Is ADDR_EXPR the right way to get the address of the array instead of > the value in a gimple_build_assign call? ADDR_EXPR is one of the "single-rhs" tree codes so you need to build a GENERIC expression here: stmt = gimple_build_assing (ptr_var, build_fold_addr_expr (array_var)); Richard. > > Steve Ellcey > sell...@imgtec.com
Re: FW: Question about Gimple FE
On Mon, Apr 6, 2015 at 11:20 PM, Sebastian Pop wrote: > On Fri, Apr 3, 2015 at 1:10 PM, Jeff Law wrote: >> On 04/03/2015 09:41 AM, Diego Novillo wrote: >>> >>> On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote: >>> I was hesitant to offer this option, but it's certainly a good >>> starting point. The representation encodes CFG, SSA, attributes, >>> declarations and annotations. It has a relatively fixed syntax, which >>> makes it easy to parse. >> >> >> Certainly using LLVM's textual format opens up a significant cans of worms, >> but there's some obvious (and some less than obvious) benefits. > > I also want to mention that LLVM's IR is not an equivalent of GCC's IR: > for instance, in GCC we have multi dimensional array types that are > missing in LLVM. > > Having an IR that is more readable than LLVM's would be nice. I still like the idea of using C + extensions most. As well as making the -fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting from dump files to generate testcases is currently somewhat awkward, mainly due to the issue how we dump labels + goto destinations. Richard. > Thanks, > Sebastian
Re: gcc 4.8.2 online docs broken
Hi Ryan, On Wed, 8 Jan 2014, Ryan Mansfield wrote: > A number of the links in 4.8.2 docs are broken (trunk seem to be OK). > > http://gcc.gnu.org/onlinedocs/4.8.2/gcc/ has 404s for the following: > > http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options > http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/IA-64-Options.html#IA-64-Options > http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/PDP-11-Options.html#PDP-11-Options > http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/TILE-Gx-Options.html#TILE-Gx-Options > http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Conditionally-supported-behavior.html#Conditionally-supported-behavior > > The w3c validator page says there's 54 broken links. It looks like anything > with a "-" in the URL is affected. thanks for this report! This was a long standing issue which, partly based on your report IIRC, I ended up fixing (by working around a "feature" in makeinfo) a bit more than a year ago. If you find any other issues on our web pages, please do not hesitate to let us know! Gerald
Re: AutoFDO profile toolchain is open-sourced
Hi, Here are some questions about AutoFDO. On 08.05.2014 02:55, Dehao Chen wrote: We have open-sourced AutoFDO profile toolchain in: https://github.com/google/autofdo For GCC developers, the most important tool is create_gcov, which converts sampling based profile to GCC-readable profile. Please refer to the readme file (https://raw.githubusercontent.com/google/autofdo/master/README) for more details. In the mentioned README file it is said that " In order to collect this profile, you will need to have an Intel CPU that have last branch record (LBR) support." Is this information obsolete? Chrome Canary builds use AutoFDO for ARMv7l (https://code.google.com/p/chromium/issues/detail?id=434587) What about Aarch64 support? Is it supported? To use the profile, one need to checkout https://gcc.gnu.org/svn/gcc/branches/google/gcc-4_8. We are working on porting AutoFDO to trunk (http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00438.html). For now AutoFDO was merged into gcc-5.0 (trunk) branch. Is it possible to backport it to 4.9 branch? Can you estimate required efforts for that? We have limited doc inside the open-sourced package, and we are planning to add more content to the wiki page (https://github.com/google/autofdo/wiki). Feel free to send me emails or discuss on github if you have any questions. Cheers, Dehao -- Best regards, Ilya
g++keeps unused objects with virtual functions
Hello GCC developer team,
I hope I am right here to address my problem with memory usage and g++:
I am writing C++ software for several very small embedded systems (8k and
smaller) and a feature with the virtual tables and the linker does not make my
life easy :-) I have a lot of objects with virtual functions, where not all of
them are used in each application, but they remain existing in the source code.
Until now I could not find a way to get rid of them in the output elf/hex file
automatically (they are not removed by the linker).
For better understanding an example:
The program:
int main()
{
for(;;)
{
// Nothing to do
}
// unreachable code
//return 0;
}
uses 62 bytes of flash and 0 bytes of RAM on an atmega8 µC (compiled with gcc
4.9.2)
When I add a not used object with virtual functions (in the below listed
example named as Derived0):
class CBase
{
public:
virtual void virtFunction() = 0;
};
class CDerived : public CBase
{
public:
virtual void virtFunction() { }
};
CDerived Derived0;
int main()
{
for(;;)
{
// Nothing to do
}
// unreachable code
//return 0;
}
the memory usage jumps up to 156 bytes flash and 8 bytes RAM usage (same
compiler 4.9.2)
compiler and linker options are:
avr-g++.exe -c -Os -Wall -fdata-sections -ffunction-sections
-fvisibility=hidden -fvisibility-inlines-hidden -fno-rtti -flto
-fuse-linker-plugin -mmcu=atmega8 ...
avr-gcc.exe -Wall -Os -Wl,-static -Wl,-flto -fuse-linker-plugin
-Wl,--strip-all -Wl,-s -Wl,--gc-sections -mmcu=atmega8 ...
The more not used objects I use the worse the problem gets.
Is there any possibility to remove unused virtual functions or at least the
objects, which are not used? I have not find any solution so far.
If not, is there a plan to add this feature to the linker?
greetings from Austria
Stefan
Re: g++keeps unused objects with virtual functions
On April 7, 2015 5:00:27 PM GMT+02:00, Stefan Ehrlich
wrote:
>Hello GCC developer team,
>I hope I am right here to address my problem with memory usage and g++:
>
>I am writing C++ software for several very small embedded systems (8k
>and smaller) and a feature with the virtual tables and the linker does
>not make my life easy :-) I have a lot of objects with virtual
>functions, where not all of them are used in each application, but they
>remain existing in the source code.
>Until now I could not find a way to get rid of them in the output
>elf/hex file automatically (they are not removed by the linker).
>
>For better understanding an example:
>
>The program:
>int main()
>{
>for(;;)
>{
> // Nothing to do
>}
>// unreachable code
>//return 0;
>}
>
>uses 62 bytes of flash and 0 bytes of RAM on an atmega8 µC (compiled
>with gcc 4.9.2)
>
>When I add a not used object with virtual functions (in the below
>listed example named as Derived0):
>
>class CBase
>{
>public:
> virtual void virtFunction() = 0;
>};
>
>class CDerived : public CBase
>{
>public:
>virtual void virtFunction() { }
>};
>
>CDerived Derived0;
>
>int main()
>{
>for(;;)
>{
> // Nothing to do
>}
>// unreachable code
>//return 0;
>}
>
>the memory usage jumps up to 156 bytes flash and 8 bytes RAM usage
>(same compiler 4.9.2)
>
>compiler and linker options are:
>avr-g++.exe -c -Os -Wall -fdata-sections -ffunction-sections
>-fvisibility=hidden -fvisibility-inlines-hidden -fno-rtti -flto
>-fuse-linker-plugin -mmcu=atmega8 ...
>avr-gcc.exe -Wall -Os -Wl,-static -Wl,-flto -fuse-linker-plugin
>-Wl,--strip-all -Wl,-s -Wl,--gc-sections -mmcu=atmega8 ...
>
>The more not used objects I use the worse the problem gets.
>
>Is there any possibility to remove unused virtual functions or at least
>the objects, which are not used? I have not find any solution so far.
>If not, is there a plan to add this feature to the linker?
I think it should already work with LTO. Maybe there are some target specifics
which make the vtables referenced?
Richard.
>greetings from Austria
>
>Stefan
>
[wwwdocs] PATCH for RE: wrong mirror on GCC mirror sites page
On Mon, 9 Mar 2015, Matthew Fortune wrote: > Conrad S writes: How did this get into the mirror list? >>> >>> Because they said they would provide mirrors: >> > https://gcc.gnu.org/ml/gcc/2014-06/msg00251.html >> > https://gcc.gnu.org/ml/gcc/2014-07/msg00156.html >> >> Upon closer inspection there's actually more junk in the mirror list >> site: >> >> Australia: http://mirrors-au.go-parts.com/gcc >> Russia: http://mirrors-ru.go-parts.com/gcc >> UK: http://mirrors-uk.go-parts.com/gcc/ >> US: http://mirrors-usa.go-parts.com/gcc > The last three here appear to work. I think you just got unlucky that > the mirrors-au one is broken at the moment. Indeed, the other three still work and mirrors-au.go-parts.com is broken, so I removed it per the patch below. Dan? Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.228 diff -u -r1.228 mirrors.html --- mirrors.html8 Feb 2015 01:02:23 - 1.228 +++ mirrors.html7 Apr 2015 18:17:08 - @@ -14,10 +14,6 @@ (Phoenix, Arizona, USA) directly: -Australia: - http://mirrors-au.go-parts.com/gcc/";>http://mirrors-au.go-parts.com/gcc -| ftp://mirrors-au.go-parts.com/gcc";>ftp://mirrors-au.go-parts.com/gcc -| rsync://mirrors-au.go-parts.com/gcc, thanks to Dan Derebenskiy (dderebens...@go-parts.com) at Go-Parts. Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, thanks to Antonin.Sprinzl at tuwien.ac.at Canada: http://gcc.parentingamerica.com";>http://gcc.parentingamerica.com, thanks to James Miller (jmiller at parentingamerica.com). Canada: http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to Sergey Ivanov (mirrors at skazkaforyou.com) @@ -42,7 +38,7 @@ Russia: http://mirrors-ru.go-parts.com/gcc/";>http://mirrors-ru.go-parts.com/gcc | ftp://mirrors-ru.go-parts.com/gcc";>ftp://mirrors-ru.go-parts.com/gcc -| rsync://mirrors-ru.go-parts.com/gcc +| rsync://mirrors-ru.go-parts.com/gcc, thanks to Dan Derebenskiy (dderebens...@go-parts.com) at Go-Parts. Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, thanks to Jan Teluch (admin at 2600.sk) UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/, thanks to mirror at mirrorservice.org UK, London: http://gcc-uk.internet.bs";>http://gcc-uk.internet.bs, thanks to Internet.bs (info at internet.bs)
Re: [wwwdocs] PATCH for RE: wrong mirror on GCC mirror sites page
Please remove that AU mirror from your list. That server has been problematic for us. We're working on getting new hosts. I'll update you when they're available. On 4/7/15 11:18 AM, Gerald Pfeifer wrote: On Mon, 9 Mar 2015, Matthew Fortune wrote: Conrad S writes: How did this get into the mirror list? Because they said they would provide mirrors: https://gcc.gnu.org/ml/gcc/2014-06/msg00251.html https://gcc.gnu.org/ml/gcc/2014-07/msg00156.html Upon closer inspection there's actually more junk in the mirror list site: Australia: http://mirrors-au.go-parts.com/gcc Russia: http://mirrors-ru.go-parts.com/gcc UK: http://mirrors-uk.go-parts.com/gcc/ US: http://mirrors-usa.go-parts.com/gcc The last three here appear to work. I think you just got unlucky that the mirrors-au one is broken at the moment. Indeed, the other three still work and mirrors-au.go-parts.com is broken, so I removed it per the patch below. Dan? Gerald Index: mirrors.html === RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v retrieving revision 1.228 diff -u -r1.228 mirrors.html --- mirrors.html8 Feb 2015 01:02:23 - 1.228 +++ mirrors.html7 Apr 2015 18:17:08 - @@ -14,10 +14,6 @@ (Phoenix, Arizona, USA) directly: -Australia: - http://mirrors-au.go-parts.com/gcc/";>http://mirrors-au.go-parts.com/gcc -| ftp://mirrors-au.go-parts.com/gcc";>ftp://mirrors-au.go-parts.com/gcc -| rsync://mirrors-au.go-parts.com/gcc, thanks to Dan Derebenskiy (dderebens...@go-parts.com) at Go-Parts. Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, thanks to Antonin.Sprinzl at tuwien.ac.at Canada: http://gcc.parentingamerica.com";>http://gcc.parentingamerica.com, thanks to James Miller (jmiller at parentingamerica.com). Canada: http://gcc.skazkaforyou.com";>http://gcc.skazkaforyou.com, thanks to Sergey Ivanov (mirrors at skazkaforyou.com) @@ -42,7 +38,7 @@ Russia: http://mirrors-ru.go-parts.com/gcc/";>http://mirrors-ru.go-parts.com/gcc | ftp://mirrors-ru.go-parts.com/gcc";>ftp://mirrors-ru.go-parts.com/gcc -| rsync://mirrors-ru.go-parts.com/gcc +| rsync://mirrors-ru.go-parts.com/gcc, thanks to Dan Derebenskiy (dderebens...@go-parts.com) at Go-Parts. Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, thanks to Jan Teluch (admin at 2600.sk) UK: ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/";>ftp://ftp.mirrorservice.org/sites/sourceware.org/pub/gcc/, thanks to mirror at mirrorservice.org UK, London: http://gcc-uk.internet.bs";>http://gcc-uk.internet.bs, thanks to Internet.bs (info at internet.bs)
Re: FW: Question about Gimple FE
On Tue, Apr 7, 2015 at 3:33 AM, Richard Biener wrote: >> Having an IR that is more readable than LLVM's would be nice. > > I still like the idea of using C + extensions most. +1 > As well as making the > -fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting > from dump files to generate testcases is currently somewhat awkward, > mainly due to the issue how we dump labels + goto destinations. +1
Re: g++keeps unused objects with virtual functions
On 04/07/2015 09:00 AM, Stefan Ehrlich wrote: > compiler and linker options are: > avr-g++.exe -c -Os -Wall -fdata-sections -ffunction-sections > -fvisibility=hidden -fvisibility-inlines-hidden -fno-rtti -flto > -fuse-linker-plugin -mmcu=atmega8 ... > avr-gcc.exe -Wall -Os -Wl,-static -Wl,-flto -fuse-linker-plugin > -Wl,--strip-all -Wl,-s -Wl,--gc-sections -mmcu=atmega8 ... > > The more not used objects I use the worse the problem gets. > > Is there any possibility to remove unused virtual functions or at least the > objects, which are not used? I have not find any solution so far. > If not, is there a plan to add this feature to the linker? Try adding -fwhole-program to the options. I haven't tried it. I believe that GCC assumes that the executable can be dynamically opened and its functions used as if it were a shared library. Because of that GCC has to keep things available. Although I would have thought visibility=hidden would have taken care of that. But -fwhole-program promises that this is the whole program and there isn't anything else linking with it. I've noticed that when specified, the output is heavily inlined and missing most function definitions so it might be what you want.
Re: Question about Gimple FE
On 15/4/7 下午4:33, "Richard Biener" wrote: >I still like the idea of using C + extensions most. As well as making the >-fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting >from dump files to generate testcases is currently somewhat awkward, >mainly due to the issue how we dump labels + goto destinations. > >Richard. What is the issue all about specifically? Does that mean we have to translate labels and gotos to conditions and loops? — Yinsong
