[GSoC] Status - 20140819
GSoC Mentors and Students, Please remember that the deadline for final evaluations is August 22 19:00UTC. Both mentors and students should submit their evaluations on GSoC website [*] by that time. So far we have only 2 evaluations (out of 10) submitted. Thank you, -- Maxim Kuvyrkov www.linaro.org
Re: LTO inhibiting dwarf lexical blocks output
On Mon, Aug 18, 2014 at 11:26 PM, Aldy Hernandez wrote: > On 08/18/14 07:31, Richard Biener wrote: >> >> On Mon, Aug 18, 2014 at 12:46 PM, Richard Biener >> wrote: >>> >>> On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote: > > >>> For the rest them on the floor instead of ICEing in dwarf2out.c. >>> */ > > > Should that read "For the rest, drop them on the floor..."??? Yes. Btw, debugging works quite well with LTO and C(-like) source, it's only when you start using C++ and its features that it breaks down completely due to missing langhooks. Like for example the libstdc++ pretty-printers not working. For example in free_lang_data_in_type we drop all FUNCTION_DECLs from TYPE_FIELDS (so you don't have any methods anymore). Such stuff is also a reason why free-lang-data runs only with -flto, otherwise we'd break debug info for non-LTO. So clearly the dwarf for types and decls we apply free_lang_data_in_X to has to be emitted before we do that. Richard. > I'm having a hard time parsing the above. > > >> The following seems to fix it. In testing now. > > > Sweet! Thanks a lot! > > And thanks for the explanations. > > Aldy >
Re: Trying to fix #61880, what characters are valid in assembler/symbol names
>> __asm__("cgo_problem_example_com_demo.Cgoexp_Dummy");
>> cgo_problem_example.com_demo.Cgoexp_Dummy
> Normally the first name looks more right.
I suppose that the reason is that the dot character ('.') while
allowed is a bit more special than the rest, right?
OK I will keep this in mind.
> The go tool will be passing a -fgo-pkgpath option to gccgo and a -gccgopkgpath
> option to cgo. You can use "go build -x" to see the exact commands being run.
Yes, I knew that but many thanks for reminding - it helped me locate
code in gcc right away.
> First make sure that those options are the same.
I checked and they are the same.
> They need to do the same thing.
They do not do the same thing.
The difference stems from these two chunks of code:
https://code.google.com/p/go/source/browse/src/cmd/cgo/out.go?name=go1.3.1#985
The definition of the 'clean' function in (p *Package)
gccgoSymbolPrefix() string
and
https://github.com/gcc-mirror/gcc/blob/gcc-4_9_0-release/gcc/go/gofrontend/gogo.cc#L250
The definition of std::string Gogo::pkgpath_for_symbol(const
std::string& pkgpath)
The second is allowing two more characters to appear as themselves in
the symbol names in addition to the a-z, A-Z, 0-9 ranges.
These are '.' and '$'.
'$' should be a rare case for the name of a directory/file, but '.' is
frequent. Additionally this
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Dollar-Signs.html
cautions against '$' - so if they are trouble it will be gcc again to
fix, not cgo.
I am sending a quick one liner patch via the code review:
https://codereview.appspot.com/125470043
Sorry for spamming with several change sets, it was only several
attempts that I found the sentence "A file may only belong to a single
active CL at a time." in http://golang.org/doc/contribute.html#tmp_11
I wanted to remove '$' and '_' from special treatment in an follow up patch.
'$' should be replaced by '_' as cgo does and '_' could be removed to
make the two functions: cgo's clear and Gogo's pkgpath_for_symbol
sintactically more similar for ease of maintenance.
But you can review and point it out there.
Kind regards:
al_shopov
[match-and-simplify] express conversions in transform ?
I was wondering how to write transform that involves conversions
(without using c_expr) ?
for eg:
(T1)(~(T2) X) -> ~(T1) X
// T1, T2 has same precision and X is an integral type not narrower than T1, T2
this could be written as:
(simplify
(convert (bit_not (convert@0 integral_op_p@1)))
if-expr
transform)
How would the transform be written ?
with c_expr we could probably write as: (is that correct?)
(bit_not { fold_convert (type, @1); })
I was wondering whether we should have an explicit support for
conversions (something equivalent of "casting") ?
sth like:
(bit_not (cast type @0))
in case we want to cast to a type of another capture
we could use:
(foo (cast (type @0) @1)) ? // cast @1 to @0's type
here type would be an operator that extracts type of the capture.
Another use of having type as an operator I guess would be for
type-matching (not sure if it's useful).
for instance:
(foo (bar @0 @1) @(type @0)@1)
that checks if @0, @1 have same types.
I was wondering on the same lines if we could introduce new
keyword "precision" analogous to type ?
(precision @0) would be short-hand for
TYPE_PRECISION (TREE_TYPE (@0))
So far I found couple patterns in fold_unary_loc with conversions
in transform:
(T1)(X p+ Y) into ((T1)X p+ Y)
(T1)(~(T2) X) -> ~(T1) X
(T1) (X * Y) -> (T1) X * (T1) Y
Thanks,
Prathamesh
Re: [match-and-simplify] express conversions in transform ?
On Tue, Aug 19, 2014 at 12:18 PM, Prathamesh Kulkarni
wrote:
> I was wondering how to write transform that involves conversions
> (without using c_expr) ?
> for eg:
> (T1)(~(T2) X) -> ~(T1) X
> // T1, T2 has same precision and X is an integral type not narrower than T1,
> T2
>
> this could be written as:
> (simplify
> (convert (bit_not (convert@0 integral_op_p@1)))
> if-expr
> transform)
>
> How would the transform be written ?
> with c_expr we could probably write as: (is that correct?)
> (bit_not { fold_convert (type, @1); })
No, unfortunately while that's correct for GENERIC it doesn't work
for GIMPLE code-gen. c_exprs are required to evaluate to
"atomics", that is, non-expressions.
> I was wondering whether we should have an explicit support for
> conversions (something equivalent of "casting") ?
> sth like:
> (bit_not (cast type @0))
Indeed simply writing
(bit_not (convert @1))
will make the code-generator "convert" @0 to its own type
(I knew the hack to simply use the first operands type is not
going to work in all cases... ;). Other conversion operators
include FIX_TRUNC_EXPR (float -> int), FLOAT_EXPR
(int -> float).
For most cases it works by accident as the outermost expression
knows its type via 'type'.
In the cases where we need to specify a type I'd like to avoid
making the type-converting operators take an additional operand.
Instead can we make it use a operator flag-with-argument? Like
(bit_not (convert:type @1))
or for the type of a capture (convert:t@2 @1).
We can also put in some more intelligence in automatically
determining the type to convert to. In your example we
know the bit_not is of type 'type' and this has to match
the type of its operands thus the 'convert' needs to convert
to 'type' as well. I'm sure there are cases we can't
auto-compute though, like chains of conversions (but not sure
they matter in practice).
So let's try that - Micha will like more intelligence in the generator ;)
I suggest to add a predicate to the generator conversion_op_p
to catch the various converting operators and then assert that
during code-gen we are going to create it with 'type' (outermost
type), not TREE_TYPE (ops[0]). Then start from the cases
we want to support and special-case (which requires passing
down the type of the enclosing expression).
Thanks,
Richard.
> in case we want to cast to a type of another capture
> we could use:
> (foo (cast (type @0) @1)) ? // cast @1 to @0's type
> here type would be an operator that extracts type of the capture.
>
> Another use of having type as an operator I guess would be for
> type-matching (not sure if it's useful).
> for instance:
> (foo (bar @0 @1) @(type @0)@1)
> that checks if @0, @1 have same types.
>
> I was wondering on the same lines if we could introduce new
> keyword "precision" analogous to type ?
> (precision @0) would be short-hand for
> TYPE_PRECISION (TREE_TYPE (@0))
>
> So far I found couple patterns in fold_unary_loc with conversions
> in transform:
> (T1)(X p+ Y) into ((T1)X p+ Y)
> (T1)(~(T2) X) -> ~(T1) X
> (T1) (X * Y) -> (T1) X * (T1) Y
>
> Thanks,
> Prathamesh
