Re: GSoC 2018: Hrishikesh Kulkarni has been selected to work on LTO dumping tool
On Sat, Apr 28, 2018 at 5:36 PM, Hrishikesh Kulkarni wrote: > Hi, > > I have created a new file lto-dump.c and to test if it's linked > correctly, I have put a dummy function called dump which should simply > print hello world after passing -dump option to lto1. > > ~/gnu-toolchain/gcc/master/tests$ ../stage1-build/gcc/lto1 hello.o -fdump > > Now while adding -fdump option in lang.opt for command line option I > am getting error “unrecognised command line option '-fdump' ”. > So how should I proceed with adding this new option. > Please find the diff file attached. +fdump +LTO Dump Tool +Call the dump function. + try fdump LTO Call the dump function. instead. The second line is magic flags that need to be recognized. You probably want instead LTO Var(flag_lto_dump) so you can test whether the flag is set or not as well. Sorry for the late response. Richard. > > Thanks, > > Hrishikesh > > On Wed, Apr 25, 2018 at 1:35 PM, Richard Biener > wrote: >> On Wed, Apr 25, 2018 at 5:17 AM, Hrishikesh Kulkarni >> wrote: >>> Hi, >>> >>> Thanks a lot for giving me this wonderful opportunity to work with GCC >>> under your guidance and mentorship (GSOC 2018). >>> >>> Just a few starting queries >>> >>>1. >>> >>>As a starting point to read lto-object file, is it sufficient to only >>>link with lto-object.c or shall I need other source files too ? >> >> You will need a lot more source files - starting with libbackend.a is >> probably easiest. As said during the initial project discussion it >> remains to be seen whether a fully standalone dump tool is >> best or whether the actual work is to be done by lto1 and the dump >> tool shall act merely as a driver around that and they communicate >> via some special (set of) options to lto1. >> >> IIRC we do not have any existing tool that builds trees or cgraph >> nodes or reads gimple bodies, so picking pices that are required >> is going to be "interesting" (and eventually will suggest some refactoring >> to avoid pulling in unnecessary stuff). You'll also run into issues >> expecting >> some initialized global state. So... >> >> ...for the first phase of experimenting with the code-base it's probably >> easiest to add some testing option to gcc/lto/lang.opt and "do stuff" >> within a if (flag_your_option) conditional from some point in >> lto/lto.c:lto_main. >> >>>2. >>> >>>Should the dump tool be under gcc or lto dir? Would I need to modify >>>only gcc/Makefile.in to add entry for building the dump tool or any other >>>Makefiles too ? >> >> I'd say it most naturally would reside in gcc/lto/ and thus its Make-lang.in >> would need to be adjusted. >> >>> >>> Also, I would proceed with copyright assignment as soon as I will receive >>> the mentioned forms. >>> >>> >>> Thanks, >>> >>> Hrishikesh >>> >>> >>> On Tue, Apr 24, 2018 at 6:27 PM, Martin Jambor wrote: >>> Hello, I am pleased to announce that Hrishikesh Kulkarni will be working on "Textual Representation of LTO Object Files (Textual LTO dump tool project)" as his Google Summer of Code 2018 project. I believe I write on behalf of everybody in the GCC community when I congratulate him and wish him success in the upcoming work. Hrishikesh's mentors are Martin Liška and Jan Hubička, but the plan is to have most of the conversation about the project on the mailing list and so I would like to encourage everyone to help him out here if they can. According to the schedule of GSoC, we have entered "Community Bonding period" which lasts until May 14th (when the first out of three "coding" periods begin). Hrishikesh, Martin and Honza will take over from me in suggesting what technical things you should study/play with, but I'd like to request that you make sure you get an FSF copyright assignment quickly (see https://gcc.gnu.org/contribute.html#legal). David, I assume that Hrishikesh does not have the assignment yet, can you please send him the necessary forms? Hrishikesh, please fill them is when you get and send them to FSF. If at any moment it will appear that the process got stuck, please let me know sooner rather than later. On a general note, GCC was given two student slots which we requested after receiving two high-quality student proposals. Unfortunately, Sebastiaan has withdrawn from GSoC 2018 before selection was announced and so we "only" have one student this year. I'm looking forward to the new tool, Martin
"position independent" vs "position-independent" in documentation
Should we standardize on "position-independent" and add it to https://gcc.gnu.org/codingconventions.html#Spelling ?
Re: Bug or feature - merging linkage declarations from static forced-inline functions
Here's a minimal test case:
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
$ cat test.cpp
extern "C"
{
void f1()
{
union some_type{
char a[2];
int b;
} variable;
}
void f2()
{
union some_type{
char a[2];
int b;
} variable;
}
}
$ arm-none-eabi-gcc test.cpp -c
test.cpp: In function 'void f2()':
test.cpp:17:5: warning: conflicting C language linkage declaration
'f2()::some_type variable'
} variable;
^~~~
test.cpp:9:5: note: previous declaration 'f1()::some_type variable'
} variable;
^~~~
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (bleeding-edge-toolchain) 8.0.1 20180427 (prerelease)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
For the problem to appear:
- functions with the types and variables have to be extern "C"
- the file must be C++
- there has to be both a type and a variable
- the variables must have identical names
Any idea whether GCC is correct in this case or maybe the error is in
the headers?
Regards,
FCh
Re: Second GCC 8.1 Release Candidate available from gcc.gnu.org
On 04/27/18 16:39, Jakub Jelinek wrote: The second release candidate for GCC 8.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180427 and shortly its mirrors. It has been generated from SVN revision 259731. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 8.1 on Wednesday, May 2nd. I bootstrapped and tested it on powerpc64 BE and LE on power8 and power9 (LE) and power 8 and power 7 (BE) and saw no problems. -- -Bill Seurer
Re: Bug or feature - merging linkage declarations from static forced-inline functions
On 30 April 2018 at 20:02, Freddie Chopin wrote:
> Here's a minimal test case:
>
> -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
>
> $ cat test.cpp
>
> extern "C"
> {
>
> void f1()
> {
> union some_type{
> char a[2];
> int b;
> } variable;
> }
>
> void f2()
> {
> union some_type{
> char a[2];
> int b;
> } variable;
> }
>
> }
>
> $ arm-none-eabi-gcc test.cpp -c
> test.cpp: In function 'void f2()':
> test.cpp:17:5: warning: conflicting C language linkage declaration
> 'f2()::some_type variable'
>} variable;
> ^~~~
> test.cpp:9:5: note: previous declaration 'f1()::some_type variable'
>} variable;
> ^~~~
This warning started with https://gcc.gnu.org/r253622
[C++ PATCH] hash-table for extern-c fns.
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00614.html
* name-lookup.c (extern_c_fns): Rename to ...
(extern_c_decls): ... here.
(check_extern_c_conflict, extern_c_linkage_bindings): Update.
(do_pushdecl): Check extern-c fns and vars.
* g++.dg/lookup/extern-c-redecl6.C: New.
* g++.dg/lookup/extern-c-hidden.C: Adjust diagnostics.
* g++.dg/lookup/extern-c-redecl.C: Likewise.
* g++.old-deja/g++.other/using9.C: Likewise.
Nathan, is this a regression for this testcase? IIUC the local types
and the local variables should have no linkage, and not conflict.
Re: Bug or feature - merging linkage declarations from static forced-inline functions
On 04/30/2018 03:21 PM, Jonathan Wakely wrote: On 30 April 2018 at 20:02, Freddie Chopin wrote: Here's a minimal test case: -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- $ cat test.cpp Nathan, is this a regression for this testcase? IIUC the local types and the local variables should have no linkage, and not conflict. that does seem plausible. Freddie, please file a bug -- Nathan Sidwell
Re: Bug or feature - merging linkage declarations from static forced-inline functions
On Mon, 2018-04-30 at 15:38 -0400, Nathan Sidwell wrote: > On 04/30/2018 03:21 PM, Jonathan Wakely wrote: > > Nathan, is this a regression for this testcase? IIUC the local > > types > > and the local variables should have no linkage, and not conflict. > > > > that does seem plausible. Freddie, please file a bug Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85580 Regards, FCh
Re: "position independent" vs "position-independent" in documentation
On 04/30/2018 05:56 AM, Jonathan Wakely wrote: Should we standardize on "position-independent" and add it to https://gcc.gnu.org/codingconventions.html#Spelling ? The same generic English usage rules apply here as to other compound phrases; hyphenate when immediately before a noun, don't hyphenate in other contexts. So "the compiler generates position-independent code" and "the compiler generates code that is position independent" are both correct. However, I don't think it's common to use "position independent" (hyphenated or not) except as a modifier for "code", so you could add "position-independent code" (rather than just "position-independent") to the glossary. -Sandra
gcc 8.0.1 RC documentation broken
I filed a bug (85578) about the documentation in: gcc-8.0.1-RC-20180427/INSTALL being broken (links not working). I filed this under 'web' as I couldn't see any documentation component. It doesn't appear to have been looked at, so just wanted to flag it up before the release tomorrow.
