Re: Returning unions (Was: Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated))
On Wed, Jun 15, 2011 at 2:47 PM, Joern Rennecke wrote:
> Quoting "H.J. Lu" :
>
>> On Tue, Jun 14, 2011 at 8:27 PM, Joern Rennecke
>> wrote:
>>>
>>> Quoting "H.J. Lu" :
>>>
Do you have a testcase for i386?
>>>
>>> struct args { int i0, i1; };
>>>
>>> union args_u { struct args *a; } __attribute__((transparent_union));
>>>
>>> union args_u
>>> f (union args_u in)
>>> {
>>> union args_u out;
>>>
>>> out.a = in.a + 1;
>>>
>>> return out;
>>> }
>>>
>>
>> Do you have a run-time testcase to show failure?
>
> No, I haven't. The assembly output should be simple enough to see
> the result at a glance. Or do you need a runtime test to plug it into
> a script? I suppose, abandoning conformity for the sake of the test,
Yes. I want to plug in a run-time test into my set up to find out
which checkin broke it if possible.
--
H.J.
Re: Returning unions (Was: Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated))
Quoting "H.J. Lu" :
On Tue, Jun 14, 2011 at 8:27 PM, Joern Rennecke wrote:
Quoting "H.J. Lu" :
Do you have a testcase for i386?
struct args { int i0, i1; };
union args_u { struct args *a; } __attribute__((transparent_union));
union args_u
f (union args_u in)
{
union args_u out;
out.a = in.a + 1;
return out;
}
Do you have a run-time testcase to show failure?
No, I haven't. The assembly output should be simple enough to see
the result at a glance. Or do you need a runtime test to plug it into
a script? I suppose, abandoning conformity for the sake of the test,
a test can be constructed by mixing caller and callee with different
ideas about the type of the return value - either have a declaration
mismatch with separate compilation, or using a function pointer cast.
C++ member function template id not matching linkage name (PR debug/49408)
Hi,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49408
struct S {
void m (int x) {}
};
template
struct K {
void f () { S s; (s.*F) (5); }
};
int main () {
K<&S::m> k;
k.f ();
}
<1><64>: Abbrev Number: 8 (DW_TAG_structure_type)
<65> DW_AT_name: K<&S::m>
^
vs.
004004de W K<&(S::m(int))>::f()
The function linkage name has prefix: K<&(S::m(int))>
But DW_AT_name of that struct is: K<&S::m>
They do not match.
But the struct DW_AT_name corresponds to the source literal 'K<&S::m>'.
So maybe the function linkage name should be changed to: 'K<&S::m>::f()'.
But changing the function linkage name would break ABI.
OTOH the function linkage name should probably refer to the fully qualified
'S::m' overload - to be able to look up 'S::m(int)' from the linkage name:
_ZN1KIXadL_ZN1S1mEiEEE1fEv
typed name
qualified name
template
name 'K'
template argument list
unary operator
operator &
typed name
qualified name
name 'S'
name 'm'
function type --- important to find 'S::m(int)'
argument list --- important to find 'S::m(int)'
builtin type int --- important to find 'S::m(int)'
name 'f'
function type
argument list
Or maybe it is not a bug and one just has to accept the function prefix may
not match its struct/class name?
Deciding how to deal with the GDB testcase:
gdb.cp/temargs.exp: test type of F in k2_m
Thanks for advice,
Jan
Re: Returning unions (Was: Re: Ping^5: Re: Updated^2: RFA: Fix middle-end/46500 (void * encapsulated))
On Tue, Jun 14, 2011 at 8:27 PM, Joern Rennecke wrote:
> Quoting "H.J. Lu" :
>
>> Do you have a testcase for i386?
>
> struct args { int i0, i1; };
>
> union args_u { struct args *a; } __attribute__((transparent_union));
>
> union args_u
> f (union args_u in)
> {
> union args_u out;
>
> out.a = in.a + 1;
>
> return out;
> }
>
Do you have a run-time testcase to show failure?
--
H.J.
the interface for cloning function
Hi, Is there an interface provided in GCC to clone the current function? I searched in the source code but failed, just in case I'm going wrong. Thanks, Feng
new wiki page: MELT performance
Hello, I have written a new page on the wiki (http://gcc.gnu.org/wiki/MELTPerformanceTest) about the performance of GCC using a MELT plugin. This can be usefull to see what take too much time in MELT (it looks like we spend a lot of time in the garbage collector, this might be highly improved). This can also help to follow the evolution of MELT in term of performance. I will also make available the plugin that I have used for the test, in order, to make new tests on the same basis. If you have any recommendation on others possibles test or on the way to run and report them, mail me! thanks
Re: libgcc: problems adding asm sources (libgcc/siditi-object.mk)
Georg-Johann Lay writes: >> If you are creating new files you can help that transition by creating >> them in libgcc rather than gcc. > > May I say that I like the "classical" setup more because all target > dependent code resides in >./gcc/config/$target > (besides some lines for adding a target and some hacks in > ./gcc/longlong.h that could easily be moved into target directory) > > I don't like that scattering of target dependent parts. Target > dependent libgcc parts could just the same way reside in >./gcc/config/$target/libgcc/ > instead of >./libgcc/config/$target/ > and maybe many other places. No, on the contrary: the goal is to have all parts (target-dependent or otherwise) of libgcc reside in libgcc and its subdirectories. This is just like all other target libraries: you don't have target-dependent libgfortran of libjava stuff in gcc/config. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libgcc: problems adding asm sources (libgcc/siditi-object.mk)
Ian Lance Taylor schrieb: > Georg-Johann Lay writes: > >> Ian Lance Taylor schrieb: >>> Georg-Johann Lay writes: >>> >> Wondering why there is now just another t-target, both t-targets >> containing snips of libgcc. > > There is a very slowly moving incomplete transition to move all the > libgcc configury support and sources from gcc/config/* to > libgcc/config/*. > > If you are creating new files you can help that transition by creating > them in libgcc rather than gcc. May I say that I like the "classical" setup more because all target dependent code resides in ./gcc/config/$target (besides some lines for adding a target and some hacks in ./gcc/longlong.h that could easily be moved into target directory) I don't like that scattering of target dependent parts. Target dependent libgcc parts could just the same way reside in ./gcc/config/$target/libgcc/ instead of ./libgcc/config/$target/ and maybe many other places. Johann
HA: How to set revision_string in version.c?
Thanks, Jonathan. I've created DEV-PHASE and now it works От: Jonathan Wakely [jwakely@gmail.com] Отправлено: 9 июня 2011 г. 20:32 Кому: Vlad Krylov Копия: gcc@gcc.gnu.org Тема: Re: How to set revision_string in version.c? On 9 June 2011 17:12, Vlad Krylov wrote: > > Hi all. > > > I see in gcc/gcc/version.c: > > /* The complete version string, assembled from several pieces. > BASEVER, DATESTAMP, DEVPHASE, and REVISION are defined by the > Makefile. */ > > In gcc/gcc/Makefile.in: > > REVISION:= $(srcdir)/REVISION > > I've created gcc/REVISION file with some number and then build new gcc. But > 'gcc -v' doesn't differ from previous build, I can't find the number. > What am I doing wrong? Help me please Does the file gcc/DEV-PHASE exist and is it non-empty?
