Re: How to get attribute of callee
Phung Nguyen schrieb: > Thank you for your reply, > > As I know, operand 0 of call is the address of called function; > operand 1 is the number of arguments; operand 2 is the number of args > as registers. Therefore, where is the info passed to call ??? As I > would like to change the target instruction of call based on the > attribute of the called function, I need the info passed to call > pattern name. > > Could you please explain more about your idea. Just have a look at the blachfin backend in bfin.c and search for 'cookie'. I use a similar machanism and it works (as far as I can tell) in all situations, even if the source messes around with pointers like casting a void pointer to an attributed function pointer. Greets > Phung
RE: Clustering switch cases
> I have been working on your patch but I didn't manage to get it > working yet. Unfortunately our current stable GCC version if 4.3.4 and > our 4.4.x still has some issues. > I tried backporting your patch to GCC 4.3.4 but it introduced several > regressions. It's my guess this is due to my incorrect manual > patching of 4.3. > Before I go through the regressions on our GCC 4.3 and try to fix the > patching, do you have by any change a patch against 4.3.x? Can you try the attached patch again with GCC 4.4.1 and let me know if it fixes your regressions. There are related changes to how basic blocks are split that may needs changing when using switch clustering. The changes to stmt.c are the same as before. The additional changes are to cfgrtl.c and cfgbuild.c. Cheers, Rahul switch_case_clusters.patch Description: switch_case_clusters.patch
Internal compiler error, gimplify.c:505. File a report?
Hi, I get an internal compiler error from the assert in gimplify.c:505 when trying out gcc-4.5.1 on RHEL 5.5 + mpc-0.8.2,mpfr-3.0.0,gmp-5.0.1. Checking out and building from gcc-4_5-branch (r163774) results in the same error. However, trunk (r163797) passes. Would this be a duplicate or should I file a new bug report including more details? I googled + bugzilla searched for internal compiler error and gimplify.c:505. I need to figure out how to subset the code to be preprocessed for public display before filing a complete report. Regards, Anders Furuhed, Pantor Engineering AB
Re: Internal compiler error, gimplify.c:505. File a report?
On Fri, Sep 3, 2010 at 09:00, Anders Furuhed wrote: > Hi, > > I get an internal compiler error from the assert in gimplify.c:505 when > trying out gcc-4.5.1 on RHEL 5.5 + mpc-0.8.2,mpfr-3.0.0,gmp-5.0.1. > Checking out and building from gcc-4_5-branch (r163774) results in the same > error. > However, trunk (r163797) passes. > Would this be a duplicate or should I file a new bug report including more > details? Please file a bug report. If it turns out to be a duplicate, it's not a big deal. Diego.
darwin weirdness
I have often heard complaints about 'weird' darwin from the various FSF gcc developers. We have made significant efforts recently to make darwin more conventional among the FSF gcc targets. For example, I currently have a patch pending for PR36502... http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00237.html which makes the handling of stack boundaries on intel darwin more generic such that stack realignments and -fstack-usage are functional (which will hopefully make us less of a regression magnet). It would be most helpful if this thread could be used to gather a list of specific darwin hacks in current gcc trunk that are considered to be objectionable so we can consider alternative fixes. I would exempt objc/obj-c++ from that list for now. Thanks in advance for any comments. Jack
Re: darwin weirdness
On Fri, 3 Sep 2010, Jack Howarth wrote: >It would be most helpful if this thread could be used to gather a > list of specific darwin hacks in current gcc trunk that are considered > to be objectionable so we can consider alternative fixes. I would > exempt objc/obj-c++ from that list for now. Thanks in advance for any > comments. I'd like to eliminate TARGET_OPTION_TRANSLATE_TABLE. As part of eliminating translate_options (replacing it with the generate .opt alias facility) I expect to temporarily move the TARGET_OPTION_TRANSLATE_TABLE support into opts-common.c - but I'd rather get rid of that sort of textual replacement of options altogether. It should be replaced by some combination of option aliases in the .opt files, conventional logic in cc1 etc. for one option to imply another, and specs (DRIVER_SELF_SPECS or otherwise). darwin.h makes the biggest use of TARGET_OPTION_TRANSLATE_TABLE, although it may be easier to replace than some targets' uses that may depend on later stages of my multilibs work for replacing them by conventional implications while still allowing multilib selection to work properly. Some darwin.h aliases are aliases for options taking more than one argument. Such options are another preculiarity of Darwin - .opt support for them will be needed (I may add it at some point as part of getting rid of WORD_SWITCH_TAKES_ARG). -- Joseph S. Myers jos...@codesourcery.com
please revert r163815/r163816
Paolo, Could you please look over PR45524 and then revert the offending r163815/r163816 that has broken decimal float support for all non-linux targets. That patch is wrong in so many ways, it is hard to know where to start... 1) Moving two sections of code from gcc/configure.ac as template and leaving behind a critical intervening section that then gets placed out of sequence. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524#c13 2) Assuming that the subtle differences between the three configure.ac's can be ignored... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45524#c11 The author needs to first solve the build issues that caused those hacks to be added before attempting to remove them from the common dfp.m4. Jack
