Re: [lto] Reader-writer compatibility?
On Tue, Sep 1, 2009 at 10:55 PM, Toon Moene wrote: > Diego Novillo wrote: > >> On Tue, Sep 1, 2009 at 11:42, Ryan Mansfield wrote: > >>> Is it required that the same compiler that generated lto objects be used >>> to >>> read them? I've come across a couple ICEs with the current revision >>> reading >>> lto objects created by a slightly older version but same configuration. >>> Is >>> this simply invalid usage of my part? >> >> It's likely. How much drift between the two revisions? Can you >> recreate the ICE if you write and read with the exact same revision? >> If so, please file a bug. > > Please add version checking. gfortran's module files (extension .mod) that > are generated from source files that contain MODULE ... END MODULE > constructs *now* contain version information. > > I still get occasionally beaten by picking up modules from 4.3 that don't > have this - you'll get all sorts of unintelligible error messages that just > distract from what's really wrong. There is bytecode version information - we just didn't bother to bump it on the branch. Richard.
Re: Trunk frozen for VTA merge
On Tue, Sep 01, 2009 at 12:37:24PM +0200, Jakub Jelinek wrote: > Subject says it all, I guess. The trunk is unfrozen again, VTA has been merged and Alex will just enable -fvar-tracking-assignments by default later today. Jakub
Re: ARM wmmx instructions from gcc ?
> So, question time again : could this be in my port, or a more > fundamental issue as Dave hints ? Both. By my reading the ABI you're trying to implement does not provide the guarantees required to use iwmmxt instructions. There are ways around this, but none of them are simple or pretty. The simplest answer is "don't do that". Paul
Re: [gcc-in-cxx] replacing qsort with std::sort
2009/9/1 Michael Matz : >> [psi...@joana obj]$ ls -lh gcc/xgcc gcc/g++ >> -rwxrwxr-x. 1 psilva psilva 481K Ago 31 12:58 gcc/g++ >> -rwxrwxr-x. 1 psilva psilva 477K Ago 31 12:58 gcc/xgcc > > That's not the real compiler, only the compiler driver. Look for files > named cc1 (the C compiler) and cc1plus (the C++ compiler) :-) Ah... So the real numbers for stripped binaries are: -rwxrwxr-x. 1 psilva psilva 42M Ago 31 17:54 std_sort/obj/gcc/cc1plus -rwxrwxr-x. 1 psilva psilva 38M Ago 31 12:59 trunk/obj/gcc/cc1plus also: textdata bss dec hex filename 12174791 23020 986004 13183815 c92b47 std_sort/obj/gcc/cc1plus 11308791 546960 461684 12317435 bbf2fb trunk/obj/gcc/cc1plus -- P.
brief update on 2 GSOC'09 GCC projects
Dear all, I got a few minutes between vacations and wanted to give you a small update on the GSOC'09 developments for GCC by Liang Peng and Yunajie Huang from ICT, China (in CC). The projects were about extending GCC to enable fine-grain optimization selection (GRAPHITE optimizations, unrolling, vectorization, inliing etc) and reordering through ICI and plugins, provide XML representation of the compilation flow. Another project was about enabling generic function cloning, fine-grain optimization of clones and program instrumentation (i.e. adding call-backs during compilation) to enable run-time selection of optimizations (using standard machine learning techniques such as decision trees and predictive modelling). I think students did a very good job and though not everything was implemented, I think it was a very good start. The students documented their developments here: http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Function_cloning_and_program_instrument ation http://ctuning.org/wiki/index.php/CTools:ICI:Projects:GSOC09:Fine_grain_tuning We use cTuning (performance tuning) collaborative website since many techniques originate from there and they are still a bit experimental but since the developments were successful and my colleagues are now extending MILEPOST GCC to improve program execution time, code size and compilation time automatically, since now on we plan to sync everything with GCC mainline and continue this work using GCC mailing list and the website. We will continue using cTuning more for collaborative program optimizations and tuning of GCC optimization heuristic. When Liang and Yuanjie are back from vacations and I am back from the wedding trip in 3 weeks, we will continue discussions about that ... In the mean time, you can check the developments here using GCC ICI SVN branch called adapt for GCC 4.4.0: http://gcc-ici.svn.sourceforge.net/viewvc/gcc-ici/branches/gcc-4.4.0-ici-2.0-adapt/ (again we hope to move all the developments from the external places to the GCC main site and to the mainline shortly). If you are interested in performance tuning and some iterative optimization results for GCC (and comparison with other compilers) including profitable cases for SPEC and EEMBC benchmarks that improve program execution time, code size and compilation time, you can check the Collective Optimization Repository here: http://ctuning.org/cdatabase The comments about those developments and suggestions to Yunajie and Liang are welcome! By the way, I think the important part of GSOC'09 was that the students got much more familiar with GCC and I hope that they and their research group in ICT will continue using and extending GCC from now on, and we will hopefully see some more interesting research results soon as well on automating program fine-grain optimization and compiler optimization heuristic construction using collective compilation and machine learning techniques ... I have to leave now and will get back in touch at the end of September ;) ... Take care, Grigori
Re: Replacing certain operations with function calls
On 09/01/2009 03:20 PM, Jean Christophe Beyler wrote: First off: does this seem correct? Yes. Though I do wonder why you are avoiding using the normal libcall machinery. If all you really care about is changing the function name, then all you need to do is modify the appropriate optab. See, for instance, arm_init_libfuncs. But if you need slightly different calling conventions, then this will work just fine. Compare this to the Alpha TFmode routines generated by alpha_emit_xfloating_libcall. However, I am unsure this is possible in the expand stage, would the expand stage automatically have this instead: mult tmp1, a, b mult tmp2, c, d mov output1, tmp1 mov output2, tmp2 call bar Yes, this is exactly what expand_call does. r~
Re: ARM wmmx instructions from gcc ?
On Wed, 2009-09-02 at 13:34 +0100, Paul Brook wrote: > > So, question time again : could this be in my port, or a more > > fundamental issue as Dave hints ? > > Both. By my reading the ABI you're trying to implement does not provide the > guarantees required to use iwmmxt instructions. There are ways around this, > but none of them are simple or pretty. The simplest answer is "don't do that". Hi Paul, Thanks for the answer, but I'm not sure what you've told me and why. Could you expand a little ? Don't do what ? Use WMMX instructions in GCC ? or Don't try to use the current implementation with WMMX ? Thanks, Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: IRA undoing scheduling decisions
Peter Bergner wrote: On Tue, 2009-09-01 at 16:46 -0400, Vladimir Makarov wrote: Peter Bergner wrote: Were you going to whip that patch up or did you want me to? I am going to do it by myself. Great! I'd like to see how your patch affects POWER6 performance. Do you have access to a POWER6 box? Yes, I have. If not, can you send Pat and I the patch and we'll fire off a run on our POWER6 benchmark system. I've got the results. SPECFP2000 is 2% better with separate udpate_equiv_regs pass but taking art volatility off (I already wrote that art is very volatile on power6: its worst and best scores can be 10-15% different) it is about 0.6% better. As for SPECINT2000, crafty failed with the separate pass. I need some time to investigate this. Without crafty, SPECInt2000 improvement is about 0.4%. So probably, it is worth to do update_equiv_reg as a separate pass. I'll submit a patch on next week (sorry, I am a bit busy this week).
VTA bootstrap compare failures
Along with the VTA merge, a change was installed that made
bootstrap-debug BUILD_CONFIG the default.
This means stage2 is built with -g0, and stage3 is built with -g, and
then we compare the object files after stripping them.
Although this works fine on numerous GNU/Linux platforms on which I
tested it, and the bootstrap-debug option has been available and
recommended, even in the trunk, for quite a while, without any problem
reports whatsoever, making it default immediately showed it hadn't got
much testing elsewhere :-(
PRs 41224 and 41228 are the ones I know about. Basically, the problem
is that stripping is not enough to get identical object files.
Significant differences remain, even after stripping.
So I guess we'll have to find a way to enable bootstrap-debug only when
this works. I can't think of a way to test whether it comparing
stripped -g0 and -g object files works using the stage1 compiler, but I
guess if we test the compiler used to build stage1 and that works, we
should strive to ensure the stage1 compiler works as well.
So tonight I'll write a patch that performs a contrib/compare-debug test
and enables or disables BUILD_CONFIG=bootstrap-debug accordingly. I
hereby ask for help, as mentioned in the bug reports, in coming up with
a minimal testcase that is enough to fail contrib/compare-debug on the
affected platforms. I assume a trivial main(){} wouldn't do, but
perhaps even that might. If you are willing to help, please test:
cat > test.c << EOF
void f() {}
EOF
gcc -c -g0 test.c -o test-g0.o
gcc -c -g test.c -o test-g.o
.../gcc/contrib/compare-debug test-g0.o test-g.o
echo $?
If it prints 0 at the end, this is too simple a testcase, and we need
something more complex to trigger a compare error. If it prints 1, we
have something we can use.
Now, if you're not interested in helping come up with this minimal
testcase, but still want bootstrap to pass, please drop bootstrap-debug
from the BUILD_CONFIG line in Makefile.in, or override BUILD_CONFIG in
the make command line.
If anyone feels this is serious and urgent enough to deserve a reversal,
please revert only the Makefile.* changes. I won't be around much for
the next 6 hours or so, but I'll deal with it as soon as I return.
Thanks,
--
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: IRA undoing scheduling decisions
On Wed, 2009-09-02 at 11:49 -0400, Vladimir Makarov wrote: > So probably, it is worth to do update_equiv_reg as a separate pass. Agreed. > I'll submit a patch on next week (sorry, I am a bit busy this week). Sounds good. Thanks for taking care of this! Peter
Re: Using MEM_EXPR inside a call expression
Adam Nemet writes: > Richard Henderson writes: >> On 09/01/2009 12:48 PM, Adam Nemet wrote: >> > I see. So I guess you're saying that there is little chance to optimize >> > the >> > loop I had in my previous email ;(. >> >> Not at the rtl level. Gimple-level loop splitting should do it though. >> >> > Now suppose we split late, shouldn't we still assume that data-flow can >> > change >> > later. IOW, wouldn't we be required to use the literal/lituse counting >> > that >> > alpha does? >> >> If you split post-reload, data flow isn't going to change >> in any significant way. >> >> > If yes then I guess it's still better to use MEM_EXPR. MEM_EXPR also has >> > the >> > benefit that it does not deem indirect calls as different when >> > cross-jumping >> > compares the insns. I don't know how important this is though. >> >> It depends on how much benefit you get from the direct >> branch. On alpha it's quite a bit, so we work hard to >> make sure that we can get one, if at all possible. > > Thanks, RTH. > > RichardS, > > Can you comment on what RTH is suggesting? Besides cross-jumping I haven't > seen indirect PIC calls get optimized much, and it seems that splitting late > will avoid the data-flow complications. > > I can experiment with this but it would be nice to get some early buy-in. > > BTW, I have the R_MIPS_JALR patch ready for submission but if we don't need to > worry about data-flow changes then using MEM_EXPR is not necessary. I guess all three would work, but TBH, I think it's too dangerous to rely on dataflow not changing in an unwanted way. We'd also have to say specifically what that way is, and preferably assert for it somehow. Personally, I like the dataflow approach you said you'd taken originally. It's the kind of thing df was designed to make easy, and we already use df in md_reorg to implement -mr10k-cache-barrier. It should just be a case of making sure that all definitions have the same value. I suppose the danger of using MEM_EXPR is that (in the MIPS case) it isn't technically correct for functions that are initially directed at a lazy-binding stub. It probably wouldn't matter in practice though, since there'll be no lazy-binding stub if the address is ever used in a different way. I don't really have any objections to using MEM_EXPR. Richard
Re: Replacing certain operations with function calls
> Yes. Though I do wonder why you are avoiding using the normal libcall > machinery. If all you really care about is changing the function name, then > all you need to do is modify the appropriate optab. See, for instance, > arm_init_libfuncs. I guess both could work. I had seen the TARGET_INIT_LIB but, when I had tried playing with it, I got a segmentation fault in the emit_unop_insn function (for some reason, pat = GEN_FCN (icode) (temp, op0) was returning NULL). I guessed that either I had another problem in my MD file that was posing a problem or that I didn't define everything needed for the libcall system. This solution worked relatively straight away and is open enough to allow me to change the implementation later down the road. When things stabilize, I might go back and move the real function calls back to the libcall machinery. >> mult tmp1, a, b >> mult tmp2, c, d >> >> mov output1, tmp1 >> mov output2, tmp2 >> call bar Ok then I don't foresee a problem with the way I do it. Thanks again all of you, Jc
LTO and adding extra information from extra passes
Hello All,
My feeling is that the Link Time Optimisation (LTO) effort should be
soon (=is expected to be, or is already) merged inside GCC trunk (future
4.5).
Several years ago, I asked if there is any possibility for an additional
pass to profit of LTO infrastructure to add some extra data into LTO
stuff (which is probably DWARF related inside ELF object files, but I am
not sure) and to retrieve it. I remember that the answer was of course not.
Now we have a working plugin infrastructure, and I believe it would be
very sensible for some plugin to register passes which add persistent
information (as does LTO with its Gimple related representation) into
object files and to retrieve it.
Is there is still a major objection against that, or is there some API
usable from plguins for that purpose?
Even the mere ability to add inside the LTO data a chunk of bytes
identified by the name of the plugin would be great. Of course, some
more features could be welcome (e.g. the ability to add data specific to
each compiled function or cgraph_node or whatever, or even to each
gimple...).
I could imagine that a plugin might be interested in adding say some
information into the object file (when ordinary compilation for LTO of a
single compilation unit happens) and later retrieve it (when link time
optimisation occur merging several object files.)
A dream case example would be a plugin for whole program static analysis.
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: LTO and adding extra information from extra passes
On Wed, Sep 2, 2009 at 10:06 PM, Basile
STARYNKEVITCH wrote:
> Hello All,
>
> My feeling is that the Link Time Optimisation (LTO) effort should be soon
> (=is expected to be, or is already) merged inside GCC trunk (future 4.5).
>
> Several years ago, I asked if there is any possibility for an additional
> pass to profit of LTO infrastructure to add some extra data into LTO stuff
> (which is probably DWARF related inside ELF object files, but I am not sure)
> and to retrieve it. I remember that the answer was of course not.
>
> Now we have a working plugin infrastructure, and I believe it would be very
> sensible for some plugin to register passes which add persistent information
> (as does LTO with its Gimple related representation) into object files and
> to retrieve it.
>
> Is there is still a major objection against that, or is there some API
> usable from plguins for that purpose?
>
> Even the mere ability to add inside the LTO data a chunk of bytes identified
> by the name of the plugin would be great. Of course, some more features
> could be welcome (e.g. the ability to add data specific to each compiled
> function or cgraph_node or whatever, or even to each gimple...).
>
> I could imagine that a plugin might be interested in adding say some
> information into the object file (when ordinary compilation for LTO of a
> single compilation unit happens) and later retrieve it (when link time
> optimisation occur merging several object files.)
>
> A dream case example would be a plugin for whole program static analysis.
The IPA pass infrastructure has all the necessary bits for this.
Richard.
> Regards.
> --
> Basile STARYNKEVITCH http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
Re: LTO and adding extra information from extra passes
Richard Guenther wrote:
On Wed, Sep 2, 2009 at 10:06 PM, Basile
STARYNKEVITCH wrote:
Hello All,
My feeling is that the Link Time Optimisation (LTO) effort should be soon
(=is expected to be, or is already) merged inside GCC trunk (future 4.5).
Several years ago, I asked if there is any possibility for an additional
pass to profit of LTO infrastructure to add some extra data into LTO stuff
(which is probably DWARF related inside ELF object files, but I am not sure)
and to retrieve it. I remember that the answer was of course not.
[...]
I could imagine that a plugin might be interested in adding say some
information into the object file (when ordinary compilation for LTO of a
single compilation unit happens) and later retrieve it (when link time
optimisation occur merging several object files.)
A dream case example would be a plugin for whole program static analysis.
The IPA pass infrastructure has all the necessary bits for this.
How do you deal with several compilation units?
I was thinking LTO is designed for that?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: LTO and adding extra information from extra passes
On Wed, Sep 2, 2009 at 10:24 PM, Basile STARYNKEVITCH wrote: > Richard Guenther wrote: >> >> On Wed, Sep 2, 2009 at 10:06 PM, Basile >> STARYNKEVITCH wrote: >>> >>> Hello All, >>> >>> My feeling is that the Link Time Optimisation (LTO) effort should be soon >>> (=is expected to be, or is already) merged inside GCC trunk (future 4.5). >>> >>> Several years ago, I asked if there is any possibility for an additional >>> pass to profit of LTO infrastructure to add some extra data into LTO >>> stuff >>> (which is probably DWARF related inside ELF object files, but I am not >>> sure) >>> and to retrieve it. I remember that the answer was of course not. > > [...] > >>> >>> I could imagine that a plugin might be interested in adding say some >>> information into the object file (when ordinary compilation for LTO of a >>> single compilation unit happens) and later retrieve it (when link time >>> optimisation occur merging several object files.) >>> >>> A dream case example would be a plugin for whole program static analysis. >> >> The IPA pass infrastructure has all the necessary bits for this. > > How do you deal with several compilation units? > > I was thinking LTO is designed for that? I of course mean the IPA pass infrastructure on the LTO branch. Richard.
adding extra libraries in branches...
Hello All
I am trying to clean up the configure.ac & Makefile.in inside the MELT
branch. [Several people rightly complained about that].
But I am not an autoconf expert. I welcome a big lot the recent update
to autoconf 2.64
I have no clear understanding of:
how to add an extra libary (free software) into the middle end [that is
is, into cc1 binary) Apparently there are several cases:
* the extra library is [L]GPL-ed & FSF-owned & blessed somehow by I
don't know who, eg GDBM or readline, so could be handled as MPFR.
* the extra library is LGPL-ed but not FSF-owned, but is required by the
branch
* the extra library is optional to the branch
Any practical hints are very welcome. If someone have time to explain it
on the wiki or the mailing list, I would be delighted.
BTW, I am trying to
make PPL & plugin machinery mandatory in the MELT branch
adding GDBM inside [1].
Regards.
NB: the motivation for GDBM is to perhaps be able to persistently store
data. http://gcc.gnu.org/ml/gcc/2009-09/msg00053.html
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: LTO and adding extra information from extra passes
Richard Guenther wrote:
A dream case example would be a plugin for whole program static analysis.
The IPA pass infrastructure has all the necessary bits for this.
How do you deal with several compilation units?
I was thinking LTO is designed for that?
I of course mean the IPA pass infrastructure on the LTO branch.
What include files describes the API?
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
MSVC hook function prologue
Hello,
After a rather long break due to other work I tried to revive my work on
support for the function prologue used in Win32 API functions on Windows - a
function prologue that some apps running in Wine expect.
This thread from January explains what I am trying to do:
http://gcc.gnu.org/ml/gcc/2009-01/msg00089.html
Essentially I want a function attrib that starts the function with this
sequence, no matter what other parameters, code in the function, attributes
or whatever are used:
8b ff mov%edi,%edi
55 push %ebp
8b ec mov%esp,%ebp
I have attached the latest version of my patch for comments. It is mainly
rebased against gcc changes that were made in the meantime. I also improved
the REG_FRAME_RELATED_EXPR notes a bit, and only set it if the movs and pops
are used for the frame pointer setup.
I also now know that I don't(or cannot) care about 64 bit right now. The
windows apps currently do Windows API function hooking only in 32 bit, and
there is no emerging scheme yet for hooking Win64 functions in the same way.
Currently I still have these problems:
*) There is apparently some plugin framework in the works. Can this
functionality implemented as a plugin?
*) The way I read the msvc_prologue attribute seems wrong to me. I could read
it directly in ix86_expand_prologue, but I got lost in the different trees
gcc uses. I'm yet again trying to find this in the code and in the docs.
*) The code generated if no frame pointer is needed isn't pretty, but Wine
will always need a frame pointer, so any optimization in that area won't get
much test exposure.
*) The stack alignment code + msvc_prologue is used by Wine on osx though.
Currently I pop %ebp after the 5 byte prologue, and the normal code recreates
the frame pointer afterwards. My understanding is that I can avoid this by
keeping the original frame pointer, but adjusting a lot of offsets after the
alignment to find the function parameters and align the stack properly on
calls. However, this is currently above my head.
*) What other changes are needed to get a functionality like this into
mainline?
Thank you,
Stefan Dösinger
Index: gcc/configure.ac
===
--- gcc/configure.ac (revision 151348)
+++ gcc/configure.ac (working copy)
@@ -3035,6 +3035,12 @@
[AC_DEFINE(HAVE_AS_IX86_SAHF, 1,
[Define if your assembler supports the sahf mnemonic.])])
+gcc_GAS_CHECK_FEATURE([swap suffix],
+ gcc_cv_as_ix86_swap,,,
+ [movl.s %esp, %ebp],,
+ [AC_DEFINE(HAVE_AS_IX86_SWAP, 1,
+[Define if your assembler supports the swap suffix.])])
+
gcc_GAS_CHECK_FEATURE([different section symbol subtraction],
gcc_cv_as_ix86_diff_sect_delta,,,
[.section .rodata
Index: gcc/config/i386/i386.h
===
--- gcc/config/i386/i386.h (revision 151348)
+++ gcc/config/i386/i386.h (working copy)
@@ -2388,6 +2388,9 @@
to be used. MS_ABI means ms abi. Otherwise SYSV_ABI means sysv abi. */
enum calling_abi call_abi;
struct machine_cfa_state cfa;
+ /* This value is used for i386 targets and specifies if the function
+ * should start with the hooking-friendly Win32 function prologue */
+ int msvc_prologue;
};
#endif
Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 151348)
+++ gcc/config/i386/i386.md (working copy)
@@ -237,6 +237,7 @@
(UNSPECV_RDTSC 18)
(UNSPECV_RDTSCP 19)
(UNSPECV_RDPMC 20)
+ (UNSPECV_VSWAPMOV 21)
])
;; Constants to represent pcomtrue/pcomfalse variants
@@ -15747,6 +15748,16 @@
(set_attr "length_immediate" "0")
(set_attr "modrm" "0")])
+(define_insn "vswapmov"
+[(unspec_volatile [(match_operand 0 "register_operand" "0")
+ (match_operand 1 "register_operand" "1")]
+ UNSPECV_VSWAPMOV )]
+ ""
+ "movl.s\t%1,%0"
+ [(set_attr "length" "2")
+ (set_attr "length_immediate" "0")
+ (set_attr "modrm" "0")])
+
;; Pad to 16-byte boundary, max skip in op0. Used to avoid
;; branch prediction penalty for the third jump in a 16-byte
;; block on K8.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 151348)
+++ gcc/config/i386/i386.c (working copy)
@@ -4777,6 +4777,19 @@
return ix86_abi;
}
+static int
+ix86_function_msvc_prologue (const_tree fntype)
+{
+ if (!TARGET_64BIT && fntype != NULL)
+{
+ if(lookup_attribute ("msvc_prologue", TYPE_ATTRIBUTES (fntype)))
+{
+ return 1;
+}
+}
+ return 0;
+}
+
static enum calling_abi
ix86_function_abi (const_tree fndecl)
{
@@ -4808,6 +4821,11 @@
cfun->machine->call_abi = ix86_abi;
else
cfun->machine->call_abi = ix86_function_type_abi (TREE_TYPE (fndecl));
+
+ if (fndecl == NULL_TREE)
+cfun->machine-
Re: MSVC hook function prologue
Currently I still have these problems:
*) There is apparently some plugin framework in the works. Can this
functionality implemented as a plugin?
No, plugins do not affect the backend.
*) The stack alignment code + msvc_prologue is used by Wine on osx though.
Currently I pop %ebp after the 5 byte prologue, and the normal code recreates
the frame pointer afterwards. My understanding is that I can avoid this by
keeping the original frame pointer, but adjusting a lot of offsets after the
alignment to find the function parameters and align the stack properly on
calls. However, this is currently above my head.
I don't think this would prevent the patch from getting the patch in.
*) What other changes are needed to get a functionality like this into
mainline?
I think right now I'd make only two cosmetic adjustments:
Here:
if (!TARGET_64BIT)
{
- warning (OPT_Wattributes, "%qE attribute only available for 64-bit",
- name);
- *no_add_attrs = true;
- return NULL_TREE;
+ if(!is_attribute_p ("msvc_prologue", name))
I'd say
if (TARGET_64BIT
? !is_attribute_p ("msvc_prologue", name))
: is_attribute_p ("msvc_prologue", name))
{
warning (OPT_Wattributes, "%qE attribute not available for "
"%d-bit", name, TARGET_64BIT ? 64 : 32);
*no_add_attrs = true;
return NULL_TREE;
}
And here:
+(define_insn "vswapmov"
+[(unspec_volatile [(match_operand 0 "register_operand" "0")
+ (match_operand 1 "register_operand" "1")]
+ UNSPECV_VSWAPMOV )]
I'd try defining the insn as
(define_insn "vswapmov"
[(set (match_operand 0 "register_operand" "0")
(match_operand 1 "register_operand" "1")
(unspec_volatile [] UNSPECV_VSWAPMOV)]
I think this should work and would be nicer to the compiler's dataflow
analysis, but it should be tested of course.
I'm not an x86 maintainer, though.
Paolo
Re: MSVC hook function prologue
2009/9/3 Paolo Bonzini :
> if (TARGET_64BIT
> ? !is_attribute_p ("msvc_prologue", name))
> : is_attribute_p ("msvc_prologue", name))
> {
> warning (OPT_Wattributes, "%qE attribute not available for "
> "%d-bit", name, TARGET_64BIT ? 64 : 32);
> *no_add_attrs = true;
> return NULL_TREE;
> }
Shouldn't it be this instead?
if (is_attribute_p ("msvc_prologue", name))
{
warning (OPT_Wattributes, "%qE attribute not available for "
"%d-bit", name, TARGET_64BIT ? 64 : 32);
*no_add_attrs = true;
return NULL_TREE;
}
as otherwise for 64-bit target warning would be shown always?
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: MSVC hook function prologue
On 09/03/2009 12:27 AM, Kai Tietz wrote:
2009/9/3 Paolo Bonzini:
if (TARGET_64BIT
? !is_attribute_p ("msvc_prologue", name))
: is_attribute_p ("msvc_prologue", name))
{
warning (OPT_Wattributes, "%qE attribute not available for "
"%d-bit", name, TARGET_64BIT ? 64 : 32);
*no_add_attrs = true;
return NULL_TREE;
}
Shouldn't it be this instead?
if (is_attribute_p ("msvc_prologue", name))
You mean TARGET_64BIT && is_attribute_p (...)?
{
warning (OPT_Wattributes, "%qE attribute not available for "
"%d-bit", name, TARGET_64BIT ? 64 : 32);
*no_add_attrs = true;
return NULL_TREE;
}
as otherwise for 64-bit target warning would be shown always?
I don't know, I was just reworking Stefan's patch. He didn't include
function names (-p) in the patch so I don't know what function this is
part of.
Paolo
Re: libstdc++.so.6.0.*-gdb.py might be installed at the wrong place
On Fri, 24 Jul 2009 09:51:07 -0600 Tom Tromey wrote: > > "Basile" == Basile STARYNKEVITCH writes: > Basile> Shouldn't a python script for gdb be installed outside of a directory > Basile> supposed to contain only ELF libraries? Wouldn't a gdb specific > Basile> subdirectory be a more appropriate place? > > Perhaps. It is a problem of several parts. Basically, gdb and all > possible users of this interface must agree on where to install such > "hook" files. > > I chose to name the .py files after the libraries and install them > alongside the libraries because it is simple and will not result in any > naming clash. > > There is also the option of installing these files underneath the > separate debug directory. However, gcc has no knowledge of that. I > assume that distros will solve this themselves by moving the file after > make install. I was just wondering if there was any consensus among distros about where to move these. We cannot keep the .py files in the location they're currently installed; ldconfig is far too noisy about it: /sbin/ldconfig: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/libstdc++.so.6.0.14-gdb.py is not an ELF file - it has the wrong magic bytes at the start. /sbin/ldconfig: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre/32/libstdc++.so.6.0.14-gdb.py is not an ELF file - it has the wrong magic bytes at the start. -- fonts, Character is what you are in the dark. gcc-porting, wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
