Re: C++ bootstrap of GCC - still useful ?
The immediate blocker to using C++ in gcc is the Ada frontend. --enable-build-with-cxx and --enable-languages=ada do not work together. Could you elaborate? -- Eric Botcazou
Advice for changing OpenMP translation
Hello, I am trying to improve OpenMP task implementation. At first I thought I just have to modify ABIs (such as GOMP_task) internal but I realised I have to change the translation of OpenMP. My question is how to change the translation of OpenMP. (I guess I should edit gcc/omp-low.c:create_omp_child_function() but how?) I checked the current translation by $ gcc -O2 -fopenmp -fdump-tree-ompexp omp_fib.c and realised a problem that limits flexibility of internal implementation. I want GOMP_taskexit ABI which is called just before functions bound to tasks (*._omp_fn.[0-9]) ends. Here a task finishes its work. My task scheduling implementation needs GOMP_taskexit ABI. For example, when the last child task of a parent task finishes its work, it tells to the parent that all of children finished their work so the parent should resume its work. Tell me how to add GOMP_taskexit ABI. Sho Nakatani
Announce: GCC MELT plugin 0.8 rc3 for GCC 4.6
Hello All,
The release candidate 3 of the MELT plugin version 0.8 for GCC 4.6 is
available as a gzipped source tar archive, from
http://gcc-melt.org/melt-0.8rc3-plugin-for-gcc-4.6.tgz of size 3356872
bytes, of md5sum 7fb95a2469948ee9ffeb10cb523ab134 (july 10th 2011). It
is extracted from MELT branch svn revision 176124
###
NEWS for 0.8rc3 MELT plugin for gcc-4.6
July 10th, 2011: Release candidate 3 of MELT plugin 0.8 for GCC 4.6
as melt-0.8rc3-plugin-for-gcc-4.6
See http://gcc-melt.org/
New features (w.r.t. MELT plugin 0.7):
* support for pragmas for MELT
* the MELT garbage collector is called less often, using the
PLUGIN_GGC_START hook.
* several new c-iterators and c-matchers.
* added static analyzing pass gccframe, useful for melt-runtime.c
* reject nested defun-s, you should use letrec or let...
* the MELT plugin is built with its MELT-Plugin-Makefile
* debug_msg, assert_msg ... should work, thanks to MELT_HAVE_DEBUG
preprocessor flag, even when melt.so is a plugin for a GCC without
checks enabled.
* melt-runtime.h has a melt_gcc_version integer variable and
melt-runtime.c should be given MELT_GCC_VERSION preprocessor
constant.
* runfile mode compiles quickly (with debug_msg support). Add new mode
translatequickly to compile quickly (with debug_msg assert_msg
support).
* the MELT building procedure builds various variants of MELT modules,
The 'optimized' variant is built with -O2 but don't support
(debug_msg ...) or (assert_msg ...). The 'quicklybuilt' variant is
built with -O0 and supports debug_msg assert_msg. The
'debugnoline' variant is mostly useful with gdb, and also supports
debug_msg assert_msg. These variants should be interoperable, you
could have a warmelt* module with 'optimized' variant and an
xtramelt* module in 'quicklybuilt' bariant.
* use the MELT_STAGE_ZERO=melt-stage0-static workaround
(bug not yet really fixed for plugins on x86 i686, ie 32 bits
machines; but this workaround is a temporary fix.)
Many bugfixes
(but some bugs remain)
###
I did not really fix the bug reported by Allan McRae on 32 bits x86 but I did
incorporate
a workaround. The plugin is building on 32 bits x86 Linux/Debian/Sid
Comments are welcome.
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Improve addsi3 for CONST_INT
2011/7/8 Georg-Johann Lay a...@gjlay.de: Denis Chertykov wrote: 2011/7/7 Georg-Johann Lay: Hi Denis. I think that it's a good question to discuss inside gcc mailing list. May be somebody more qualified person give a better suggestion than me. ...bringing this over to gcc mailing list I think about improving addsi3 insn when a const_int is added. The hard case is when the register to add the value is not in d. In the current implementation the constant simply gets reloaded into some register (provided it is not an easy const like 1 or -1). That's a waste because * a 32-bit register gets initialized with the const, but a 8-bit d-register would be sufficient. * Instead of setting an intermediate register, the value could be added byte-by-byte if one d-reg was available. A bit unsure about how to approach that, I'd ask you what you think about it. I can think of three approaches: 1) Use a peep2 on sequence like *reload_insi *addsi3 resp. *movsi *addsi3 2) Add new insn with (clobber (match_scratch:QI =d)) 3) Allow all const_int in *addsi3. If peep2 comes up with a d-clobber, that's fine. Else have to cook up a clobber by saving a d-reg to tmp_reg similar to movsi implementation. Approach (1) has the advantage that it is neutral with respect to reloading. However, reload will always allocate a SI register, even if peep2 comes up with a scratch. But, CSE will always have a chance to optimize it. You mean CSE or reload-CSE? As I remember reload himself can optimize such cases, also postreload CSE. If same constant is used multiple times, CSE can arrange for that and combine can can compose a addsi+clobber. combine will only insert the constant if it can reduce the number of insns, i.e. if two insns need the same constant it won't do the replacement. Approach (2) has the advantage that it has just pressure 1 on d-regs whilst (1) and the current implementation have pressure 4 or even r-regs. IMHO it's good idea to check. I am in favor of approach (3): It's easier pattern like (1) and it does not put pressure on regs at all. Also (3) makes no additional work to support SF or if there were fixed-point mode. It's a fake. Generally, all fake methods is a wrong way. (Look at fake addressing) Yes, it's a fake. Bot note that movsi r,i alternative is also a fake, and maybe you remember my failed approach to use secondary reloads for that: http://gcc.gnu.org/ml/gcc/2011-03/msg00290.html A word on fake addressing (PR46278): You were right with that. At the time you wrote the AVR port, there was nothing like MODE_CODE_BASE_REG_CLASS or REGNO_MODE_CODE_OK_FOR_BASE_P. And even today it's not possible to specify different costs for different addressing modes (ADDRESS_COST won't do it because it wors on anatomy of an address and not on the address reg(s) invented). If there was a way to tell the costs to IRA/reload and these passes cared for the costs, fake addressing would be no problem! There are architectures where LOAD R, [A] resp. LOAD R, [B] do exactly the same but have different costs because A can be used implicitly and thus yields shorter code. There's no way to tell it to the allocator. All you can do is define reg-alloc-order and hope for the best. I think that I WAS WRONG while I decide to create __zero_reg__ and __tmp_reg__. (It was derived from my low qualify at start of EGCS hacking) I thought about that topic already more than once. I have no idea how it could be done better. OPTIMIZE_MODE_SWITCHING looks rempting but it runs prior to reload, and many uses of ZERO or TMP generated in reload or peep2. We would need a pass with similar abilities running after peep2. To test in ISR if ZERO or TMP is needed, insn attributes could help. But the stack layout would have to be changed ad-hoc, new BE-pass was needed and it's error-prone IMHO. Introducing new ZERO_REG like R2 would change the ABI and ISR pro/epilogue would increase even more because some insns change/restore ZERO. Or do you think the improvement is not needed? I vote for 2, but I can be wrong. You know the best way ;-) Try all methods and compare results. (profile optimizing yourself ;-) Thanks for your recommendation. I want to give you a recomendation: please, cleanup the port from using immediate numbers as register numbers. (in your patches you frequently use it) I intend to do more backend cleanup, the elfos patch just was the first. Please, use constants ! I forgot to point to them in your last patches. e.i. /* We have no clobber reg but need one. Cook one up. That's cheaper than loading from constant pool. */ cooked_clobber_p = true; clobber_reg = gen_rtx_REG (QImode, 31); Use REG_Z + 1 instead of 31. Already committed: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00634.html Few years ago I have an idea to use register
MELT plugin 0.8rc for 4.6 on 32 bits x86
On Sat, 09 Jul 2011 10:08:06 +1000
Allan McRae al...@archlinux.org wrote:
On 09/07/11 01:43, Basile Starynkevitch wrote:
On Fri, 08 Jul 2011 19:50:11 +1000
Allan McRaeal...@archlinux.org wrote:
On 08/07/11 19:15, Basile Starynkevitch wrote:
On Fri, Jul 08, 2011 at 06:41:30PM +1000, Allan McRae wrote:
empty-file-for-melt.c
cc1: note: MELT is bootstrapping so ignore builtin source directory
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/melt-source and module
directory
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/libexec/melt-modules
*** WARNING *** there are active plugins, do not report this as a
bug unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT | melt
PLUGIN_FINISH| melt
PLUGIN_GGC_START | melt
PLUGIN_GGC_MARKING | melt
PLUGIN_ATTRIBUTES| melt
PLUGIN_START_UNIT| melt
PLUGIN_PRAGMAS | melt
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
Did you install a previous release of MELT plugin (e.g. 0.8rc1 or 0.7)? If
you did, you have to remove it entirely (eg remove all files named
*melt*)?
Alexandre Lissy discovered that by replacing, in file
melt-0.8rc2-plugin-for-gcc-4.6/melt-build.mk line 420,
MELT_STAGE_ZERO?= melt-stage0-dynamic
with
MELT_STAGE_ZERO = melt-stage0-static
the bug disappears.
Allan, could you confirm that it is the case for you also? Thanks!
I can confirm the build completes with that change.
For your information, I corrected that bug (not only made the
workaround) on MELT svn rev. 176125.
So I think that the MELT plugin 0.8 final
(which I will probably release in a couple of days) will have that bug
corrected.
Before releasing the definitive MELT 0.8 plugin for 4.6, I want to be
sure that the new building machinery (based upon MELT-Plugin-Makefile,
i.e. using make) is working for someone else than me.
As soon as someone give me reports (either positive or negative) about
the build of MELT plugin 0.8 rc3 which I have announced an hour ago
http://gcc.gnu.org/ml/gcc/2011-07/msg00126.html
http://groups.google.com/group/gcc-melt/browse_thread/thread/8901c8fcf47c8f32
I will be able to release the final 0.8 (but I am not working at all
tomorrow).
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
MELT plugin 0.8rc4 for 4.6
On Sun, 10 Jul 2011 19:00:14 +0200
Basile Starynkevitch bas...@starynkevitch.net wrote:
For your information, I corrected that bug (not only made the
workaround) on MELT svn rev. 176125.
So I think that the MELT plugin 0.8 final
(which I will probably release in a couple of days) will have that bug
corrected.
I just released MELT plugin 0.8rc4 with that change. See http://gcc-melt.org/
and download
http://gcc-melt.org/melt-0.8rc4-plugin-for-gcc-4.6.tgz
When I have a successful build report, I will release it as MELT 0.8 plugin.
Same news (w.r.t to MELT 0.7) as in
http://gcc.gnu.org/ml/gcc/2011-07/msg00126.html
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: C++ bootstrap of GCC - still useful ?
On 07/10/2011 06:45 AM, Ian Lance Taylor wrote: Toon Moenet...@moene.org writes: As of a couple of months, I perform a bootstrap-with-C++ (--enable-build-with-cxx) daily on my machine between 18:10 and 20:10 UTC. I see that the build by a C++ compiler has been the subject of the GCC Gathering at Google: C++ style and migration crowlwriting and using C++ in gcc It is not quite clear what the outcome of this discussion was. Is there still interest in daily builds like mine ? Yes, it's definitely useful. The immediate blocker to using C++ in gcc is the Ada frontend. --enable-build-with-cxx and --enable-languages=ada do not work together. Ah, OK. Just drop me a note when a regular test including Ada starts to be useful (I probably have to skip some other front end language in favor Ada to stay within the two hour elapsed time window between two weather forecasting runs). BTW, the ultimate reason I asked was that it turned out that running an ordinary quad core PC to the max doesn't come for free. Last month I got past year's electricity bill - it turns out that I am now (16 hours of weather forecasting and 4 hours of GCC bootstrapping per day) using 3200 KWh a year - to the tune of 1100 Euros. So the question whether a run is useful is certainly relevant :-) -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: C++ bootstrap of GCC - still useful ?
On Sun, Jul 10, 2011 at 1:03 PM, Toon Moene t...@moene.org wrote: BTW, the ultimate reason I asked was that it turned out that running an ordinary quad core PC to the max doesn't come for free. Last month I got past year's electricity bill - it turns out that I am now (16 hours of weather forecasting and 4 hours of GCC bootstrapping per day) using 3200 KWh a year - to the tune of 1100 Euros. Ouch! :-/ So the question whether a run is useful is certainly relevant :-) Indeed :-)
Re: Advice for changing OpenMP translation
On Sun, Jul 10, 2011 at 09:36:15PM +0900, Sho Nakatani wrote: I am trying to improve OpenMP task implementation. At first I thought I just have to modify ABIs (such as GOMP_task) internal but I realised I have to change the translation of OpenMP. My question is how to change the translation of OpenMP. (I guess I should edit gcc/omp-low.c:create_omp_child_function() but how?) I checked the current translation by $ gcc -O2 -fopenmp -fdump-tree-ompexp omp_fib.c and realised a problem that limits flexibility of internal implementation. I want GOMP_taskexit ABI which is called just before functions bound to tasks (*._omp_fn.[0-9]) ends. Here a task finishes its work. My task scheduling implementation needs GOMP_taskexit ABI. Why? If your GOMP_taskexit is the last thing the *._omp_fn.[0-9] task body will do, what is the difference between that and just the point when the task body function returns? If you want to do something after GOMP_taskexit, you should explain what and why. Jakub
Re: C++ bootstrap of GCC - still useful ?
On Sun, 2011-07-10 at 20:03 +0200, Toon Moene wrote: On 07/10/2011 06:45 AM, Ian Lance Taylor wrote: Toon Moenet...@moene.org writes: As of a couple of months, I perform a bootstrap-with-C++ (--enable-build-with-cxx) daily on my machine between 18:10 and 20:10 UTC. I see that the build by a C++ compiler has been the subject of the GCC Gathering at Google: C++ style and migration crowlwriting and using C++ in gcc It is not quite clear what the outcome of this discussion was. Is there still interest in daily builds like mine ? Yes, it's definitely useful. The immediate blocker to using C++ in gcc is the Ada frontend. --enable-build-with-cxx and --enable-languages=ada do not work together. Ah, OK. Just drop me a note when a regular test including Ada starts to be useful (I probably have to skip some other front end language in favor Ada to stay within the two hour elapsed time window between two weather forecasting runs). BTW, the ultimate reason I asked was that it turned out that running an ordinary quad core PC to the max doesn't come for free. Last month I got past year's electricity bill - it turns out that I am now (16 hours of weather forecasting and 4 hours of GCC bootstrapping per day) using 3200 KWh a year - to the tune of 1100 Euros. So the question whether a run is useful is certainly relevant :-) Hi, Since I pay the electricty bill of some compile farm machines I understand you here :). New generation of hardware has made significant progress on energy efficiency: my latest built PC is a Intel core i7 2600 4 cores 8 threads 3.4 GHz 4x4 GB of RAM with 40 GB SSD + 2TB HDD, 80+ gold PSU and it idles around 30W and uses 110W full CPU load. PC cost is around 800 EUR in France (19.6% VAT included). According to your data it should reduce your bill by a factor of three (365W = 110W), so it should pay itself in around a year: 720 EUR less on your yearly electricity bill, assuming you counted only your PC power consumption in your figures. And bonus nearly no noise in a case with 2 or 3 120mm fans. I haven't had a chance to test AMD A8 processors but I will do soon. Sincerely, Laurent
Re: MELT plugin 0.8rc4 for 4.6
On 11/07/11 03:15, Basile Starynkevitch wrote: On Sun, 10 Jul 2011 19:00:14 +0200 Basile Starynkevitchbas...@starynkevitch.net wrote: For your information, I corrected that bug (not only made the workaround) on MELT svn rev. 176125. So I think that the MELT plugin 0.8 final (which I will probably release in a couple of days) will have that bug corrected. I just released MELT plugin 0.8rc4 with that change. See http://gcc-melt.org/ and download http://gcc-melt.org/melt-0.8rc4-plugin-for-gcc-4.6.tgz When I have a successful build report, I will release it as MELT 0.8 plugin. Same news (w.r.t to MELT 0.7) as in http://gcc.gnu.org/ml/gcc/2011-07/msg00126.html I can give a successful build report for melt-0.8rc4 on i686-pc-linux-gnu using make all. Some issues I noticed with make install make DESTDIR=/tmp/melt install ... install: target `/tmp/melt//usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/include/' is not a directory: No such file or directory This needs added to install-melt-includes: $(mkinstalldirs) $(DESTDIR)/$(MELTGCC_PLUGIN_DIR)/include/ Then I run into an error in install-melt-modules: install: cannot stat `melt-modules/*.so': No such file or directory In that directory I have three subdirectories containing built modules. I guess one of them is supposed to be used. All other install targets work fine. Allan
Re: GSOC - Student Roundup
On 06.07.2011 11:39, Pierre Vittet wrote: Hi, I am Pierre Vittet, one of the GSOC students. I am writing a plugin which is a simple statical analysis tools. The idea is to write some tests (like testing that a function call is tested to return somethings (not) null, or testing that a call to a given function is followed by a call to another function.), that can be parametrized by the user (to be run on the functions he wants to check). I feel it can be a useful tool (however I am ready to fight with false positives). I am using MELT (http://gcc-melt.org/) for this, I know that is quite a hot topic in the community and it is not much considered. MELT aims at abstracting GCC internal with a higher level language. I think that it can be a good way to enter into GCC, because it permits to parse quite quikly the GCC internal, gimple especially. The major feature of MELT is his pattern matching on tree ability. Part of my work is to improve MELT (as I need some features which were not implemented), such as having handling pragma in MELT plugins or gluing some GCC dominance functions (from gcc/dominance.c) However, like the others students which answered to this thread, the main difficulty is understanding and eventually modifying GCC itself. That is quite time consumming, as you can have, even to write a simple patch, to know well several parts of GCC (I am often grepping for a given struct or function). I also thing that each pass could be more detailled. Sometimes, it is hard to find a pass in the code from it's dump file name. I had to write a patch for the trunk, to add a data field to pragma handlers, this was quite a simple patch, however, I had to make it compatible with the fact that one of the function I was modifying was used many times in differents parts of GCC. Currently, I need to understand how works C++ mangling if I want my plugin to work with C++ (I am going to write a new mail about this), as I need to convert the string given by the user into the function(s) that it represents. About the state of my plugin, I have written the core of the module. It can use user's input from different entries (I have already written an entrie using the pragma, and an entrie using direct argument (given when invoking GCC), searchs if it matchs a corresponding test and generate a new GCC Pass from this. This new pass is inserted after ssa pass, as I got a representation which suits to me (I can find the information my tests need). But the choice of inserting here is quite empirical (would have you choice another pass?). The plugin is mainly tested for C code, even if I would like to have C++ working too. I have started implementing tests, for the moment I use a test which checks that there is a test checking for a NULL pointer (if resCall == NULL for exemple) after a given function call, and return a warning if there is no test. I have also started implementing a test checking that a given is immediatly followed by another given function. I would also try to add a test checking that a call to a given function is followed by a call to another function in the same function bodies, I know that I will have to handle the basic block hierarchie, that why I glued dominance functions into MELT. I think, I am in time, however, this is sometimes hard to evaluate: for exemple, I don't know really how much time, I will take to manage C++ function in my plugin. I feel sad, not being able to use IRC from my web access (in my school)... and so only communicating by mail with the GCC community. However, I thanks the community for their answer and support. The point to improve, I guess, is having more people reviewing patchs (even if, I understand that it requires a lot of time and skills). Thanks Pierre Vittet On 05/07/2011 21:08, Daniel Carrera wrote: Hello Philip + Dimitrios Thanks for your posts. I am another GSOC student. I am working on the Fortran front-end of GCC (gfortran). Like most GFortran developers, my background is more in the natural sciences (astrophysics in my case) rather than computer science. My project is to help add coarray support for GFortran. Coarrays are a cool new feature in the Fortran 2008 standard that give Fortran native support for parallel programming (as opposed to using MPI or OpenMP). Scientific simulations (especially in parallel clusters) are the bread and butter of Fortran. Learning how GCC works has been difficult but rewarding. My work is split between the libgfortran library, which is straight forward enough, and the Fortran front-end, which at first looked like gobbledygook. Today I can actually understand most front-end functions when I read them, but it took a long time to get to this point. GCC has a scary learning curve. The libgfortran library is more forgiving for the beginner. We are using MPI as the backend to implement coarrays and I have very much enjoyed learning MPI. So far my contributions
[Bug c++/44609] Invalid template code causes infinite loop of error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #7 from Jason Merrill jason at gcc dot gnu.org 2011-07-10 05:32:10 UTC --- This isn't actually an infinite loop; it's a sequence of recursive instantiations which hit an error in each instantiation of the same function. Eventually it will hit the maximum template instantiation depth and stop, but that takes a very long time with the default -ftemplate-depth. It probably makes sense not to continue to instantiate a template after one instantiation has produced an error.
[Bug target/39633] [avr] loop bug: missing 8-bit comparison (*cmpqi)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39633
--- Comment #10 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-10
08:29:04 UTC ---
Created attachment 24729
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24729
Minimal test case
Here is a minimal testcase:
char c;
void func_1 (char a)
{
a = a 7;
if (a)
c = a;
}
Code with 4.6.1 -Os -dp -S -mmcu=atmega88:
func_1:
lsl r24 ; 6ashrqi3/5[length = 2]
sbc r24,r24
breq .L1 ; 8branch[length = 1]
sts c,r24 ; 10*movqi/3[length = 2]
.L1:
ret ; 20return[length = 1]
[Bug testsuite/49694] FAIL: gnat.dg/specs/debug1.ads scan-assembler-times byte\t0x1\t# DW_AT_artificial 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49694 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2011-07-10 08:53:44 UTC --- debug1.ads failed in the same way on armv5tel-linux-gnueabi with 4.7-20110702.
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 --- Comment #9 from janus at gcc dot gnu.org 2011-07-10 09:31:31 UTC --- (In reply to comment #8) Janus, what's the status of this PR? I think only backporting is missing, is that correct? Right. I'm just about to apply the backport ...
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 PcX xunxun1982 at gmail dot com changed: What|Removed |Added CC||xunxun1982 at gmail dot com --- Comment #12 from PcX xunxun1982 at gmail dot com 2011-07-10 10:03:48 UTC --- (In reply to comment #11) FWIW, using mingw.org's gcc-4.5.2 release, the test passes: $ g++ -fopenmp omp_test.c -o omp_test -lpthread $ ./omp_test.exe OMP : All looks good Relevant installation data: gcc-core-4.5.2-1-mingw32-bin gcc-c++-4.5.2-1-mingw32-bin libgcc-4.5.2-1-mingw32-dll-1 libstdc++-4.5.2-1-mingw32-dll-6 libgomp-4.5.2-1-mingw32-dll-1 mingwrt-3.18-mingw32-dll mingwrt-3.18-mingw32-dev w32api-3.17-2-mingw32-dev pthreads-w32-2.8.0-3-mingw32-dev libpthread-2.8.0-3-mingw32-dll-2 I believe this is because TLS support was added to the mingw(32) runtime in late Jan 2010, thanks to Kai's work: http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3550 (Although a full compiler suite, and mingw runtime, with TLS support was not officially released until March 2010) I don't thinks so. Because mingw64 crt also contains TLS support written by Kai, but mingw64 crt also use the code to crash.
[Bug tree-optimization/49695] New: conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695
Summary: conditional moves for stores
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: revital.e...@linaro.org
for (i = 0; i point1-len; i++)
{
if (point1-arr[i].val)
{
point1-arr[i].val ^= (unsigned long long) res;
}
}
For the above loop if-conversion is not been done in the tree level (compiled
with trunk -r176116). Seemingly this case is similar to the one in PR27313.
When using -ftree-loop-if-convert-stores I get 'tree could trap...' message
although I'm not sure why as there is a read in every iteration of the loop to
the memory location we write to.
Similar case appears in SPEC2006/libquantum.
Here's a snippet from .ifcvt file:
bb 3:
pretmp.6_33 = point1_3(D)-arr;
bb 4:
# i_27 = PHI i_22(7), 0(3)
i.0_6 = (unsigned int) i_27;
D.3689_7 = i.0_6 * 8;
D.3690_8 = pretmp.6_33 + D.3689_7;
D.3691_9 = D.3690_8-val;
if (D.3691_9 != 0)
goto bb 5;
else
goto bb 6;
bb 5:
D.3694_20 = (long long unsigned int) res_19(D);
D.3695_21 = D.3694_20 ^ D.3691_9;
D.3690_8-val = D.3695_21;
bb 6:
i_22 = i_27 + 1;
if (i_22 D.3696_29)
goto bb 7;
else
goto bb 8;
bb 7:
goto bb 4;
[Bug tree-optimization/49695] conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695 --- Comment #1 from revital.eres at linaro dot org 2011-07-10 10:05:07 UTC --- Created attachment 24730 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24730 Testcase which contains the loop
[Bug target/39633] [avr] loop bug: missing 8-bit comparison (*cmpqi)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39633
--- Comment #11 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-10
10:15:11 UTC ---
It's bug in avr.c:notice_update_cc() because for shift offset=7 cc0 is set as
if it contained meaningful state:
case CC_CLOBBER:
/* Insn doesn't leave CC in a usable state. */
CC_STATUS_INIT;
/* Correct CC for the ashrqi3 with the shift count as CONST_INT != 6 */
set = single_set (insn);
if (set)
{
rtx src = SET_SRC (set);
if (GET_CODE (src) == ASHIFTRT
GET_MODE (src) == QImode)
{
rtx x = XEXP (src, 1);
if (GET_CODE (x) == CONST_INT
INTVAL (x) 0
INTVAL (x) != 6)
{
cc_status.value1 = SET_DEST (set);
cc_status.flags |= CC_OVERFLOW_UNUSABLE;
}
}
}
break;
[Bug target/49696] New: ICE on mips when compiling drizzle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49696 Summary: ICE on mips when compiling drizzle Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: aurel...@aurel32.net Host: mips-unknown-linux-gnu Target: mips-unknown-linux-gnu Build: mips-unknown-linux-gnu Created attachment 24731 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24731 Testcase to reproduce the issue When building drizzle on mips, g++ crash with an internal compiler error. The problem is reproducible with versions 4.4, 4.5 and 4.6, but not with version 4.3 (I didn't test earlier versions). I have attached a reduced testcase. $ g++ -c ./testcase-min.ii ./testcase-min.ii: In member function 'drizzled::internal::gcc_traitsT, D::value_type drizzled::internal::gcc_traitsT, D::fetch(const volatile value_type*) const volatile [with T = bool, D = bool, drizzled::internal::gcc_traitsT, D::value_type = bool]': ./testcase-min.ii:12:5: error: unrecognizable insn: (insn 16 15 17 3 (parallel [ (set (reg:SI 205) (mem/v:SI (reg:SI 200) [-1 S4 A32])) (set (mem/v:SI (reg:SI 200) [-1 S4 A32]) (unspec_volatile:SI [ (reg:SI 203) (reg:SI 204) (plus:SI (reg:SI 205) (const_int 0 [0])) ] UNSPEC_SYNC_OLD_OP_12)) (clobber (scratch:SI)) ]) ./testcase-min.ii:11 -1 (nil)) ./testcase-min.ii:12:5: internal compiler error: in extract_insn, at recog.c:2109 Please submit a full bug report, with preprocessed source if appropriate.
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 --- Comment #10 from janus at gcc dot gnu.org 2011-07-10 11:50:09 UTC --- Author: janus Date: Sun Jul 10 11:50:04 2011 New Revision: 176117 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176117 Log: 2011-07-10 Janus Weil ja...@gcc.gnu.org PR fortran/49562 * expr.c (gfc_check_vardef_context): Handle type-bound procedures. 2011-07-10 Janus Weil ja...@gcc.gnu.org PR fortran/49562 * gfortran.dg/typebound_proc_23.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/typebound_proc_23.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/expr.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from janus at gcc dot gnu.org 2011-07-10 11:52:35 UTC --- Fixed on trunk and 4.6. Closing. Also: Thanks for reporting, Hans-Werner!
[Bug c++/49538] [4.7 regression] Revision 175341 causes segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538 --- Comment #10 from Jarryd Beck jarrydb at cse dot unsw.edu.au 2011-07-10 12:20:26 UTC --- *** Bug 49587 has been marked as a duplicate of this bug. ***
[Bug c++/49587] Code generation error with dynamic libraries.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49587 Jarryd Beck jarrydb at cse dot unsw.edu.au changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #6 from Jarryd Beck jarrydb at cse dot unsw.edu.au 2011-07-10 12:20:26 UTC --- It is definitely a duplicate of bug 49538 which is fixed now, and my problem is fixed. So I am marking this as resolved. *** This bug has been marked as a duplicate of bug 49538 ***
[Bug tree-optimization/49695] conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695
--- Comment #2 from revital.eres at linaro dot org 2011-07-10 12:50:31 UTC ---
(In reply to comment #0)
for (i = 0; i point1-len; i++)
{
if (point1-arr[i].val)
{
point1-arr[i].val ^= (unsigned long long) res;
}
}
For the above loop if-conversion is not been done in the tree level (compiled
with trunk -r176116). Seemingly this case is similar to the one in PR27313.
When using -ftree-loop-if-convert-stores I get 'tree could trap...' message
although I'm not sure why as there is a read in every iteration of the loop to
the memory location we write to.
hmmm... after reading Sebastian Pop's paper from the last summit (Improving
GCC’s auto-vectorization with if-conversion and loop
flattening for AMD’s Bulldozer processors) it's seems that we need to grantee
that point1-arr[i].val is writable when the condition is false which we can
not prove in this case. So that's not a bug, I apologize for the noise.
[Bug tree-optimization/49695] conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695 --- Comment #3 from revital.eres at linaro dot org 2011-07-10 13:41:07 UTC --- the memory location we write to. hmmm... after reading Sebastian Pop's paper from the last summit (Improving GCC’s auto-vectorization with if-conversion and loop flattening for AMD’s Bulldozer processors) it's seems that we need to grantee that point1-arr[i].val is writable when the condition is false which we can not prove in this case. So that's not a bug, I apologize for the noise. Continuing reading the paper I see that under the 'If-conversion without restrictions' section there is a technique that allows to apply if-conversion in the above case by writing to artificial object that has been created by the compiler when the condition is false. I assume this method is not implemented in trunk yet.
[Bug c++/49691] ICE in cp_parser_late_return_type_opt, at cp/parser.c:15562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49691 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2011-07-10 14:24:06 UTC --- Author: jason Date: Sun Jul 10 14:24:03 2011 New Revision: 176120 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176120 Log: PR c++/49691 * parser.c (cp_parser_late_return_type_opt): Check quals parameter rather than current_class_type to determine whether to set 'this'. (cp_parser_direct_declarator): Pass -1 to quals if member_p is false. (cp_parser_init_declarator): Pass down member_p. Added: trunk/gcc/testsuite/g++.dg/cpp0x/regress/regress6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash45.C trunk/gcc/testsuite/g++.dg/template/crash38.C trunk/gcc/testsuite/g++.dg/template/crash64.C
[Bug c++/49691] ICE in cp_parser_late_return_type_opt, at cp/parser.c:15562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49691 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2011-07-10 14:25:31 UTC --- Fixed.
[Bug fortran/49690] [4.6/4.7 regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1019
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49690 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-10 14:28:51 UTC --- Author: burnus Date: Sun Jul 10 14:28:48 2011 New Revision: 176121 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176121 Log: 2011-07-10 Tobias Burnus bur...@net-b.de PR fortran/49690 * intrinsic.c (add_functions): Use BT_VOID for 2nd argument of * SIGNAL. 2011-07-10 Tobias Burnus bur...@net-b.de PR fortran/49690 * gfortran.dg/intrinsic_signal.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_signal.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug lto/49697] New: read permission of LTO intermediate files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49697 Summary: read permission of LTO intermediate files Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch not sure if this is a bug, but LTO generates intermediate files in $TMPDIR that are readable by all -rw-r--r-- cleUTZi.ltrans17.ltrans.o instead of the usual -rw--- for other gcc files that appear in $TMPDIR
[Bug fortran/49698] New: Unmanageable compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49698 Summary: Unmanageable compiler error Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fmarti...@gmv.com Created attachment 24732 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24732 The file where the error is generated at line 1495 The submitted code generates the following error that I cannot debug with the provided information. t_element_pure_vector_ftl.f90: In function ‘ftl_vector_init’: t_element_pure_vector_ftl.f90:1495:0: error: type mismatch in binary expression integer(kind=8) integer(kind=8) integer(kind=4) num.25 = num.25 + 1; t_element_pure_vector_ftl.f90:1495: confused by earlier errors, bailing out The compiler options are -g -std=f2003 -fprofile-arcs -ftest-coverage -fbacktrace -fbounds-check -fno-range-check -fconvert=big-endian -Wall This code compiles and runs properly with intel 11, 12 and g95
[Bug fortran/49698] Unmanageable compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49698 --- Comment #1 from Fran Martinez Fadrique fmartinez at gmv dot com 2011-07-10 17:30:21 UTC --- Created attachment 24733 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24733 Base type used in the module generating the error
[Bug target/44707] operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707 David Fang fang at csl dot cornell.edu changed: What|Removed |Added CC||fang at csl dot cornell.edu --- Comment #8 from David Fang fang at csl dot cornell.edu 2011-07-10 17:34:25 UTC --- Hi, I see this test failing on powerpc-darwin8 (I know, not a critical platform). http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01092.html What information can I provide from my test runs?
[Bug fortran/49690] [4.6/4.7 regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1019
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49690 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-10 18:27:17 UTC --- Author: burnus Date: Sun Jul 10 18:27:12 2011 New Revision: 176126 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176126 Log: 2011-07-10 Tobias Burnus bur...@net-b.de PR fortran/49690 * intrinsic.c (add_functions): Use BT_VOID for 2nd argument of * SIGNAL. 2011-07-10 Tobias Burnus bur...@net-b.de PR fortran/49690 * gfortran.dg/intrinsic_signal.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/intrinsic_signal.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/intrinsic.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/49690] [4.6/4.7 regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1019
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49690 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-10 18:30:00 UTC --- FIXED on the trunk and on the 4.6 branch (for 4.6.2). Thanks, Matthias, for the GCC bugreport - and thanks to Alastair for the original bugreport (at bugs.debian.org).
[Bug other/49665] 'defined in discarded section' link failures on cpu2006 benchmarks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49665 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added Component|c++ |other --- Comment #5 from Pat Haugen pthaugen at gcc dot gnu.org 2011-07-10 18:43:28 UTC --- The problems still exist in r176125, although looks like a couple from soplex went away but a couple new ones for omnetpp showed up. soplex: `soplex::SPxBasis::~SPxBasis()' referenced in section `.data.rel.ro._ZTVN6soplex8SPxBasisE[vtable for soplex::SPxBasis]' of spxbasis.o: defined in discarded section `.group' of spxbasis.o `soplex::SPxLP::~SPxLP()' referenced in section `.data.rel.ro._ZTVN6soplex5SPxLPE[vtable for soplex::SPxLP]' of spxlp.o: defined in discarded section `.grou p' of spxlp.o omnetpp: `cStdDev::~cStdDev()' referenced in section `.data.rel.ro._ZTV7cStdDev[vtable for cStdDev]' of libs/sim/cstat.o: defined in discarded section `.group' of libs/sim/cstat.o `cStatistic::~cStatistic()' referenced in section `.data.rel.ro._ZTV10cStatistic[vtable for cStatistic]' of libs/sim/std/netpack.o: defined in discarded section `.group' of libs/sim/std/netpack.o `cEqdHistogramBase::~cEqdHistogramBase()' referenced in section `.data.rel.ro._ZTV17cEqdHistogramBase[vtable for cEqdHistogramBase]' of libs/sim/std/netpack.o: defined in discarded section `.group' of libs/sim/std/netpack.o
[Bug other/49665] 'defined in discarded section' link failures on cpu2006 benchmarks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49665 --- Comment #6 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-07-10 19:08:14 UTC --- Another thing you might check is to revert the commit pointed out here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533#c5 and see if this makes any difference.
[Bug target/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.2, 4.7.0 Resolution||FIXED Known to fail||4.6.1 --- Comment #14 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-10 20:57:18 UTC --- Closed as FIXED for 4.6.2
[Bug target/39633] [avr] loop bug: missing 8-bit comparison (*cmpqi)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39633 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug target/39212] ice for AVR target: unable to find a register to spill in class 'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39212 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||gjl at gcc dot gnu.org Known to work||4.5.2, 4.6.1 Known to fail|| --- Comment #5 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-07-10 21:13:46 UTC --- Eric, can I close this for 4.6.2?
[Bug target/48803] arm: Bad assembler produced by bit extract/shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48803 Michael Hope michael.hope at linaro dot org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #2 from Michael Hope michael.hope at linaro dot org 2011-07-11 00:19:52 UTC --- Part of the difference is that 4.5 inlines the other functions and 4.6 doesn't. Adding an __attribute__((always_inline)) to both gives the following: For 4.5, main is: main: movwr3, #22136 movtr3, 4660 and r3, r0, r3 cbnzr3, .L10 mvn r3, #15 lslsr2, r0, r3 ubfxr0, r0, #30, #10 and r3, r0, #768 lsrsr0, r2, #24 orr r0, r3, r0 bx lr .L10: ubfxr3, r0, #22, #2 lsrsr0, r0, #24 lslsr3, r3, #8 orr r0, r3, r0 bx lr For 4.6 it becomes: main: movwr3, #22136 movtr3, 4660 andsr3, r3, r0 cbz r3, .L13 ubfxr3, r0, #22, #2 lsrsr0, r0, #24 lslsr3, r3, #8 .L12: orrsr0, r0, r3 bx lr .L13: mov r0, r3 b .L12
[Bug target/49699] New: Aligned load on unaligned address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49699
Summary: Aligned load on unaligned address
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
[hjl@gnu-6 tmp]$ cat a.c
#include emmintrin.h
struct foo
{
__m128 x;
} __attribute__ ((aligned(8)));
extern struct foo x;
__m128
foo ()
{
return x.x;
}
[hjl@gnu-6 tmp]$ gcc -msse2 -O a.c -S
[hjl@gnu-6 tmp]$ cat a.s
.filea.c
.text
.globlfoo
.typefoo, @function
foo:
.LFB516:
.cfi_startproc
movapsx(%rip), %xmm0
ret
.cfi_endproc
.LFE516:
.sizefoo, .-foo
.identGCC: (GNU) 4.6.0 20110530 (Red Hat 4.6.0-9)
.section.note.GNU-stack,,@progbits
[hjl@gnu-6 tmp]$
[Bug tree-optimization/49601] [4.7 Regression] ICE at ipa-inline-analysis.c:1188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49601 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.11 02:55:49 CC||amodra at gmail dot com Ever Confirmed|0 |1 --- Comment #2 from Alan Modra amodra at gmail dot com 2011-07-11 02:55:49 UTC --- Confirmed with powerpc64 20110706
[Bug target/44707] operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707 Jack Howarth howarth at nitro dot med.uc.edu changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #9 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-11 03:03:55 UTC --- On powerpc-apple-darwin9, this fails under gcc-4.6.1 as... Executing on host: /sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/gcc/ -O1 -w -c -m32 -o pr44707.o /sw/src/fink.build/gcc46-4.6.1-1000/gcc-4.6.1/gcc/testsuite/gcc.c-torture/compile/pr44707.c (timeout = 300) /var/tmp//ccZ2tK1u.s:15:non-relocatable subtraction expression, _w minus L001$pb^M /var/tmp//ccZ2tK1u.s:15:symbol: _w can't be undefined in a subtraction expression^M /var/tmp//ccZ2tK1u.s:14:non-relocatable subtraction expression, _w minus L001$pb^M /var/tmp//ccZ2tK1u.s:14:symbol: _w can't be undefined in a subtraction expression^M /var/tmp//ccZ2tK1u.s:13:non-relocatable subtraction expression, _v minus L001$pb^M /var/tmp//ccZ2tK1u.s:13:symbol: _v can't be undefined in a subtraction expression^M /var/tmp//ccZ2tK1u.s:12:non-relocatable subtraction expression, _v minus L001$pb^M /var/tmp//ccZ2tK1u.s:12:symbol: _v can't be undefined in a subtraction expression^M compiler exited with status 1 which may be an assembler issue remembering that darwin is using the rather old... Apple Inc version cctools-698.1~1, GNU assembler version 1.38
[Bug target/44707] operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707 --- Comment #10 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-11 03:07:34 UTC --- Created attachment 24734 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24734 preprocessed source for pr44707.c from powerpc-apple-darwin9
[Bug target/44707] operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707 --- Comment #11 from Jack Howarth howarth at nitro dot med.uc.edu 2011-07-11 03:08:07 UTC --- Created attachment 24735 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24735 assembly for pr44707.c from powerpc-apple-darwin9
[Bug middle-end/49699] Aligned load on unaligned address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49699 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Component|target |middle-end --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2011-07-11 03:13:16 UTC --- It looks like a middle-end bug.
Re: [rfc, i386] Convert output_mi_thunk to rtl
On Sun, Jul 10, 2011 at 3:34 AM, Richard Henderson r...@redhat.com wrote: I developed this patch while working on the dwarf2 pass series. This was before I bypassed the entire problem by removing the !deep branch prediction paths. Ideally, we'd do this generically from gimple. Less ideally, but still better, is to always emit rtl, and support that in the middle end without so many hacks in the back end. Looks good to me! + reload_completed = 1; + epilogue_completed = 1; Do we really need these? Perhaps a comment should be added here, it is not obvious at the first sight... + tmp_regno = CX_REG; if ((ccvt (IX86_CALLCVT_FASTCALL | IX86_CALLCVT_THISCALL)) != 0) tmp_regno = AX_REG; if (...) tmp_regno = AX_REG; else tmp_regno = CX_REG; Uros.
Re: [Patch, Fortran] PR - fix SIGNAL intrinsic (4.6/4.7 Regression)
On Saturday 09 July 2011 20:59:08 Tobias Burnus wrote:
The regression seems to be a side effect of the -fwhole-file effort.
The BT_UNKNOWN of the second argument of SIGNAL(NUMBER,HANDLER) triggers
an ICE in trans-types.c, when generating the decl for the external
function signal (or rather for __gfortran_signal_func{,_int}).
As both handler == integer expression and handler == subroutine
proc-pointer are pointers, it seems to be simplest to translate the
second argument as void * (BT_VOID).
Build and regtested on x86-64-linux.
OK for the trunk and the 4.6 branch?
OK.
Re: PATCH [2/n] X32: Turn on 64bit and check models for x32
On Sat, Jul 9, 2011 at 11:22 PM, H.J. Lu hongjiu...@intel.com wrote: This patch turns on 64bit and check models for x32. OK for trunk? Thanks. H.J. --- 2011-07-09 H.J. Lu hongjiu...@intel.com * config/i386/i386.c (ix86_option_override_internal): Turn on OPTION_MASK_ISA_64BIT for TARGET_X32. Only allow small and small PIC models for TARGET_X32. OK. Thanks, Uros.
C++ PATCH for c++/49691 (ICE in cp_parser_late_return_type_opt)
My patch to implement DR 1207 caused this regression, where within a
member function, a tentative parse that could involve a
trailing-return-type leads to confusion. Fixed by not relying on
current_class_type to decide whether or not we're declaring a member
function.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1393efb69e650d966116c88a74efe2a1a014fa84
Author: Jason Merrill ja...@redhat.com
Date: Sat Jul 9 16:30:53 2011 -0400
PR c++/49691
* parser.c (cp_parser_late_return_type_opt): Check quals parameter
rather than current_class_type to determine whether to set 'this'.
(cp_parser_direct_declarator): Pass -1 to quals if member_p is false.
(cp_parser_init_declarator): Pass down member_p.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 6bb15ed..64be923 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -14388,7 +14388,7 @@ cp_parser_init_declarator (cp_parser* parser,
= cp_parser_declarator (parser, CP_PARSER_DECLARATOR_NAMED,
ctor_dtor_or_conv_p,
/*parenthesized_p=*/NULL,
- /*member_p=*/false);
+ member_p);
/* Gather up the deferred checks. */
stop_deferring_access_checks ();
@@ -14971,8 +14971,8 @@ cp_parser_direct_declarator (cp_parser* parser,
/* Parse the virt-specifier-seq. */
virt_specifiers = cp_parser_virt_specifier_seq_opt (parser);
- late_return
- = cp_parser_late_return_type_opt (parser, cv_quals);
+ late_return = (cp_parser_late_return_type_opt
+ (parser, member_p ? cv_quals : -1));
/* Create the function-declarator. */
declarator = make_call_declarator (declarator,
@@ -15538,7 +15538,10 @@ cp_parser_virt_specifier_seq_opt (cp_parser* parser)
- trailing-type-specifier-seq abstract-declarator(opt)
- Returns the type indicated by the type-id. */
+ Returns the type indicated by the type-id.
+
+ QUALS is either a bitmask of cv_qualifiers or -1 for a non-member
+ function. */
static tree
cp_parser_late_return_type_opt (cp_parser* parser, cp_cv_quals quals)
@@ -1,7 +15558,7 @@ cp_parser_late_return_type_opt (cp_parser* parser, cp_cv_quals quals)
/* Consume the -. */
cp_lexer_consume_token (parser-lexer);
- if (current_class_type)
+ if (quals = 0)
{
/* DR 1207: 'this' is in scope in the trailing return type. */
tree this_parm = build_this_parm (current_class_type, quals);
diff --git a/gcc/testsuite/g++.dg/cpp0x/regress/regress6.C b/gcc/testsuite/g++.dg/cpp0x/regress/regress6.C
new file mode 100644
index 000..6de64c0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/regress/regress6.C
@@ -0,0 +1,11 @@
+// PR c++/49691
+// { dg-options -std=c++0x }
+
+struct A { int x; };
+A* f();
+struct B {
+ void g()
+ {
+int(f()-x);
+ }
+};
diff --git a/gcc/testsuite/g++.dg/parse/crash45.C b/gcc/testsuite/g++.dg/parse/crash45.C
index 8696ab4..d2fbc8c 100644
--- a/gcc/testsuite/g++.dg/parse/crash45.C
+++ b/gcc/testsuite/g++.dg/parse/crash45.C
@@ -3,5 +3,5 @@
struct A
{
- template class int f (B); // { dg-error was not declared in this scope|cannot be a member template }
+ template class int f (B); // { dg-error was not declared in this scope|cannot be a member template|has not been declared }
};
diff --git a/gcc/testsuite/g++.dg/template/crash38.C b/gcc/testsuite/g++.dg/template/crash38.C
index c652cc8..f4cf299 100644
--- a/gcc/testsuite/g++.dg/template/crash38.C
+++ b/gcc/testsuite/g++.dg/template/crash38.C
@@ -4,5 +4,5 @@ class A
{
templateclass R
static void f(X); // { dg-error }
- inline void A::fvoid(X); // { dg-error f|expected }
+ inline void A::fvoid(X); // { dg-error f|expected|not been declared }
};
diff --git a/gcc/testsuite/g++.dg/template/crash64.C b/gcc/testsuite/g++.dg/template/crash64.C
index 750e3da..1d8fd00 100644
--- a/gcc/testsuite/g++.dg/template/crash64.C
+++ b/gcc/testsuite/g++.dg/template/crash64.C
@@ -2,5 +2,5 @@
struct A
{
- templateint void foo()(0); // { dg-error initializer }
+ templateint void foo()(0); // { dg-error }
};
Re: PATCH [3/n] X32: Promote pointers to Pmode
On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu hongjiu...@intel.com wrote:
X32 psABI requires promoting pointers to Pmode when passing/returning
in registers. OK for trunk?
Thanks.
H.J.
--
2011-07-09 H.J. Lu hongjiu...@intel.com
* config/i386/i386.c (ix86_promote_function_mode): New.
(TARGET_PROMOTE_FUNCTION_MODE): Likewise.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 04cb07d..c852719 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree
fntype_or_decl,
return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
}
+/* Pointer function arguments and return values are promoted to
+ Pmode. */
+
+static enum machine_mode
+ix86_promote_function_mode (const_tree type, enum machine_mode mode,
+ int *punsignedp, const_tree fntype,
+ int for_return)
+{
+ if (for_return != 1 type != NULL_TREE POINTER_TYPE_P (type))
+ {
+ *punsignedp = POINTERS_EXTEND_UNSIGNED;
+ return Pmode;
+ }
+ return default_promote_function_mode (type, mode, punsignedp, fntype,
+ for_return);
+}
Please rewrite the condition to:
if (for_return == 1)
/* Do not promote function return values. */
;
else if (type != NULL_TREE ...)
Also, please add some comments.
Your comment also says that pointer return arguments are promoted to
Pmode. The documentation says that:
FOR_RETURN allows to distinguish the promotion of arguments and
return values. If it is `1', a return value is being promoted and
`TARGET_FUNCTION_VALUE' must perform the same promotions done here.
If it is `2', the returned mode should be that of the register in
which an incoming parameter is copied, or the outgoing result is
computed; then the hook should return the same mode as
`promote_mode', though the signedness may be different.
You bypass promotions when FOR_RETURN is 1.
Uros.
Re: [rfc, i386] Convert output_mi_thunk to rtl
On 07/10/2011 02:33 AM, Uros Bizjak wrote: On Sun, Jul 10, 2011 at 3:34 AM, Richard Henderson r...@redhat.com wrote: I developed this patch while working on the dwarf2 pass series. This was before I bypassed the entire problem by removing the !deep branch prediction paths. Ideally, we'd do this generically from gimple. Less ideally, but still better, is to always emit rtl, and support that in the middle end without so many hacks in the back end. Looks good to me! + reload_completed = 1; + epilogue_completed = 1; Do we really need these? Dunno. Copied them from ia64. I'll run the testsuite again without. + tmp_regno = CX_REG; if ((ccvt (IX86_CALLCVT_FASTCALL | IX86_CALLCVT_THISCALL)) != 0) tmp_regno = AX_REG; if (...) tmp_regno = AX_REG; else tmp_regno = CX_REG; If you insist. r~
Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant
On Sat, Jul 9, 2011 at 23:31, H.J. Lu hjl.to...@gmail.com wrote: On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini bonz...@gnu.org wrote: On 07/05/2011 04:27 PM, H.J. Lu wrote: diff --git a/gcc/explow.c b/gcc/explow.c index 7387dad..b343bf8 100644 --- a/gcc/explow.c +++ b/gcc/explow.c @@ -383,18 +383,13 @@ convert_memory_address_addr_space (enum machine_mode to_mode ATTRIBUTE_UNUSED, case PLUS: case MULT: - /* For addition we can safely permute the conversion and addition - operation if one operand is a constant and converting the constant - does not change it or if one operand is a constant and we are - using a ptr_extend instruction (POINTERS_EXTEND_UNSIGNED 0). - We can always safely permute them if we are making the address - narrower. */ + /* For addition we safely permute the conversion and addition + operation if one operand is a constant since we can't generate + new instructions. We can always safely permute them if we are + making the address narrower. */ if (GET_MODE_SIZE (to_mode) GET_MODE_SIZE (from_mode) || (GET_CODE (x) == PLUS - CONST_INT_P (XEXP (x, 1)) - (XEXP (x, 1) == convert_memory_address_addr_space - (to_mode, XEXP (x, 1), as) - || POINTERS_EXTEND_UNSIGNED 0))) + CONST_INT_P (XEXP (x, 1 return gen_rtx_fmt_ee (GET_CODE (x), to_mode, convert_memory_address_addr_space (to_mode, XEXP (x, 0), as), This does not seem safe to me. The current code is broken for x32. See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47727 We can't generate any new instructions. Do you have any suggestions. By safe I mean that the new condition might be too wide and generate wrong code. Richard is definitely right in comment 6, generating new code in simplify-rtx is a no-no (see its usage of gen_lowpart_no_emit). Paolo
ObjC: hide encoding obstacks inside objc-encoding.c
This Objective-C patch does an obvious cleanup of the encoding code internal
API, by hiding
the obstacks used to create the encoding strings inside objc-encoding.c. This
provides
a cleaner, simpler API, and improves code modularity.
In practice, the patch makes the following changes:
* have objc-act.c use the new objc_encoding_init() instead of setting up the
obstacks directly;
* improve encode_field_decl() to take only the field_decl as argument, and
return the encoding
string as identifier instead of requiring callers to access and manipulate
the obstacks directly.
* consequent cleanups, including removing dependency of various files from
obstack.h.
Ok to commit ?
Thanks
Index: objc/objc-encoding.c
===
--- objc/objc-encoding.c(revision 176090)
+++ objc/objc-encoding.c(working copy)
@@ -53,18 +53,24 @@ along with GCC; see the file COPYING3. If not see
/* Set up for use of obstacks. */
#include obstack.h
-/* This obstack is used to accumulate the encoding of a data type.
- TODO: Make this static. */
-struct obstack util_obstack;
+/* This obstack is used to accumulate the encoding of a data type. */
+static struct obstack util_obstack;
/* This points to the beginning of obstack contents, so we can free
- the whole contents. TODO: Make this static. */
-char *util_firstobj;
+ the whole contents. */
+static char *util_firstobj;
+void objc_encoding_init (void)
+{
+ gcc_obstack_init (util_obstack);
+ util_firstobj = (char *) obstack_finish (util_obstack);
+}
+
int generating_instance_variables = 0;
static void encode_type_qualifiers (tree);
static void encode_type (tree, int, int);
+static void encode_field (tree field_decl, int curtype, int format);
static tree
objc_method_parm_type (tree type)
@@ -470,7 +476,7 @@ encode_aggregate_fields (tree type, bool pointed_t
obstack_1grow (util_obstack, '');
}
- encode_field_decl (field, curtype, format);
+ encode_field (field, curtype, format);
}
}
@@ -802,8 +808,8 @@ encode_gnu_bitfield (int position, tree type, int
obstack_grow (util_obstack, buffer, strlen (buffer));
}
-void
-encode_field_decl (tree field_decl, int curtype, int format)
+static void
+encode_field (tree field_decl, int curtype, int format)
{
#ifdef OBJCPLUS
/* C++ static members, and things that are not fields at all,
@@ -828,6 +834,25 @@ encode_gnu_bitfield (int position, tree type, int
encode_type (TREE_TYPE (field_decl), curtype, format);
}
+tree
+encode_field_decl (tree field_decl)
+{
+ tree result;
+
+ encode_field (field_decl,
+ obstack_object_size (util_obstack),
+ OBJC_ENCODE_DONT_INLINE_DEFS);
+
+ /* Null terminate string. */
+ obstack_1grow (util_obstack, 0);
+
+ /* Get identifier for the string. */
+ result = get_identifier (XOBFINISH (util_obstack, char *));
+ obstack_free (util_obstack, util_firstobj);
+
+ return result;
+}
+
/* This routine encodes the attribute of the input PROPERTY according
to following formula:
Index: objc/ChangeLog
===
--- objc/ChangeLog (revision 176090)
+++ objc/ChangeLog (working copy)
@@ -1,3 +1,30 @@
+2011-07-10 Nicola Pero nicola.p...@meta-innovation.com
+
+ * objc-encoding.h (obstack.h): Do not include.
+ (util_obstack, util_firstobj): Do not declare.
+ (encode_field_decl): Updated prototype to return a tree and take a
+ single tree argument. Updated comments.
+ * objc-encoding.c (util_obstack, util_firstobj): Made static.
+ (objc_encoding_init): New.
+ (encode_field_decl): Existing function renamed to encode_field and
+ made static. New encode_field_decl wrapper function added.
+ (encode_aggregate_fields): Update call to encode_field_decl to
+ call encode_field.
+ * objc-next-runtime-abi-02.c (obstack.h): Do not include.
+ (util_obstack, util_firstobj): Do not declare.
+ (build_v2_ivar_list_initializer): Updated call to
+ encode_field_decl.
+ * objc-runtime-shared-support.c (obstack.h): Do not include.
+ (util_obstack, util_firstobj): Do not declare.
+ (build_ivar_list_initializer): Updated call to encode_field_decl.
+ * objc-act.c (objc_init): Use objc_encoding_init.
+ * Make-lang.in (objc/objc-runtime-shared-support.o): Do not depend
+ on OBSTACK_H.
+ (objc/objc-gnu-runtime-abi-01.o): Likewise.
+ (objc/objc-next-runtime-abi-01.o): Likewise.
+ (objc/objc-next-runtime-abi-02.o): Likewise.
+ (objc/objc-act.o): Likewise.
+
2011-07-04 Nicola Pero nicola.p...@meta-innovation.com
Refactored encoding code into objc-encoding.h and objc-encoding.c.
Index: objc/objc-encoding.h
===
--- objc/objc-encoding.h(revision 176090)
+++
Re: [PATCH] New IPA-CP with real function cloning
/* If checking is enabled, verify that no lattice is in the TOP state, i.e.
not
bottom, not containing a variable component and without any known value at
the same time. */
static void
verify_propagated_values (void)
{
#ifdef ENABLE_CHECKING
Hmm, would not be better to keep this function around to be called from
debugger, like
other verifiers do?
struct cgraph_node *node;
FOR_EACH_DEFINED_FUNCTION (node)
{
struct ipa_node_params *info = IPA_NODE_REF (node);
int i, count = ipa_get_param_count (info);
for (i = 0; i count; i++)
{
struct ipcp_lattice *lat = ipa_get_lattice (info, i);
if (!lat-bottom
!lat-contains_variable
lat-values_count == 0)
{
if (dump_file)
{
fprintf (dump_file, \nIPA lattices after constant
propagation:\n);
print_all_lattices (dump_file, true, false);
}
gcc_unreachable ();
}
}
}
#endif
}
/* Propagate values through a pass-through jump function JFUNC associated with
edge CS, taking values from SRC_LAT and putting them into DEST_LAT.
SRC_IDX
is the index of the source parameter. */
static bool
propagate_vals_accross_pass_through (struct cgraph_edge *cs,
struct ipa_jump_func *jfunc,
struct ipcp_lattice *src_lat,
struct ipcp_lattice *dest_lat,
int src_idx)
{
struct ipcp_value *src_val;
bool ret = false;
if (jfunc-value.pass_through.operation == NOP_EXPR)
for (src_val = src_lat-values; src_val; src_val = src_val-next)
ret |= add_value_to_lattice (dest_lat, src_val-value, cs,
src_val, src_idx);
else if (edge_within_scc (cs))
ret = set_lattice_contains_variable (dest_lat);
Hmm, is the reason for not using artimetic within SCC documented somewhere?
It seems like code someone will eventually run into and remove without much of
consideration.
/* Calculate devirtualization time bonus for NODE, assuming we know KNOWN_CSTS
and KNOWN_BINFOS. */
static int
devirtualization_time_bonus (struct cgraph_node *node,
VEC (tree, heap) *known_csts,
VEC (tree, heap) *known_binfos)
Eventually it would be nice to make this common with inliner analysis. We want
to
increase inlining limits here too
/* Only bare minimum benefit for clearly un-inlineable targets. */
res += 1;
callee = cgraph_get_node (target);
if (!callee)
continue;
Hmm, when you test it here, you might probably ask if callee is analyzed and
inlinable then ;)
/* Return true if cloning NODE is a good idea, given the estimated
TIME_BENEFIT
and SIZE_COST and with the sum of frequencies of incoming edges to the
potential new clone in FREQUENCIES. */
static bool
good_cloning_opportunity_p (struct cgraph_node *node, int time_benefit,
int freq_sum, gcov_type count_sum, int size_cost)
{
if (time_benefit == 0
|| !flag_ipa_cp_clone
|| !optimize_function_for_speed_p (DECL_STRUCT_FUNCTION (node-decl)))
return false;
Still I think cloning oppurtunity is good if the saving on call size reduce
enough
to pay back for function body duplication.
It would probably make sense then to create simple wrapper functions instead of
duplicating the function body.
gcc_checking_assert (size_cost = 0);
/* FIXME: These decisions need tuning. */
if (max_count)
{
int evaluation, factor = (count_sum * 1000) / max_count;
evaluation = (time_benefit * factor) / size_cost;
if (dump_file (dump_flags TDF_DETAILS))
fprintf (dump_file, good_cloning_opportunity_p (time: %i,
size: %i, count_sum: HOST_WIDE_INT_PRINT_DEC
) - evaluation: %i, threshold: %i\n,
time_benefit, size_cost, (HOST_WIDE_INT) count_sum,
evaluation, 500);
return evaluation 500;
Hmm, the magic numbers looks a bit scary... putting size and time into fraction
causes problem that the units are not really related.
But we will see. I guess we will need the 500 as --param value however.
We probably want ipa-profile to collect expected running time of the unit
and then we can do something like computing relative speedup of unit versus
relative growth of it that is sort of better defined and closer to
temperature metrics. (but of course off reality)
}
else
{
int evaluation = (time_benefit * freq_sum) / size_cost;
if (dump_file (dump_flags TDF_DETAILS))
fprintf (dump_file, good_cloning_opportunity_p (time: %i,
size: %i, freq_sum: %i) - evaluation: %i, threshold: %i\n,
Re: [rfc, i386] Convert output_mi_thunk to rtl
I developed this patch while working on the dwarf2 pass series. This was before I bypassed the entire problem by removing the !deep branch prediction paths. Ideally, we'd do this generically from gimple. Less ideally, but still better, is to always emit rtl, and support that in the middle end without so many hacks in the back end. Being able to emit variadic thunks through the standard channels would be cool. I was thinking about this to make cgraph code not having to special case the thunks, but eventually gave up concluding that it is very nnatural to actually repesent thunk call in gimple. The patch looks fine to me, especially because we will need fewer hacks for x32.. Honza
Re: PATCH [3/n] X32: Promote pointers to Pmode
On Sun, Jul 10, 2011 at 7:32 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Jul 9, 2011 at 11:28 PM, H.J. Lu hongjiu...@intel.com wrote:
X32 psABI requires promoting pointers to Pmode when passing/returning
in registers. OK for trunk?
Thanks.
H.J.
--
2011-07-09 H.J. Lu hongjiu...@intel.com
* config/i386/i386.c (ix86_promote_function_mode): New.
(TARGET_PROMOTE_FUNCTION_MODE): Likewise.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 04cb07d..c852719 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -7052,6 +7061,23 @@ ix86_function_value (const_tree valtype, const_tree
fntype_or_decl,
return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
}
+/* Pointer function arguments and return values are promoted to
+ Pmode. */
+
+static enum machine_mode
+ix86_promote_function_mode (const_tree type, enum machine_mode mode,
+ int *punsignedp, const_tree fntype,
+ int for_return)
+{
+ if (for_return != 1 type != NULL_TREE POINTER_TYPE_P (type))
+ {
+ *punsignedp = POINTERS_EXTEND_UNSIGNED;
+ return Pmode;
+ }
+ return default_promote_function_mode (type, mode, punsignedp, fntype,
+ for_return);
+}
Please rewrite the condition to:
if (for_return == 1)
/* Do not promote function return values. */
;
else if (type != NULL_TREE ...)
Also, please add some comments.
Your comment also says that pointer return arguments are promoted to
Pmode. The documentation says that:
FOR_RETURN allows to distinguish the promotion of arguments and
return values. If it is `1', a return value is being promoted and
`TARGET_FUNCTION_VALUE' must perform the same promotions done here.
If it is `2', the returned mode should be that of the register in
which an incoming parameter is copied, or the outgoing result is
computed; then the hook should return the same mode as
`promote_mode', though the signedness may be different.
You bypass promotions when FOR_RETURN is 1.
Uros.
Here is the updated patch. OK for trunk?
Thanks.
--
H.J.
--
2011-07-10 H.J. Lu hongjiu...@intel.com
* config/i386/i386.c (ix86_promote_function_mode): New.
(TARGET_PROMOTE_FUNCTION_MODE): Likewise.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 04cb07d..1b02312 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2973,6 +2973,9 @@ ix86_option_override_internal (bool main_args_p)
SUBSUBTARGET_OVERRIDE_OPTIONS;
#endif
+ if (TARGET_X32)
+ix86_isa_flags |= OPTION_MASK_ISA_64BIT;
+
/* -fPIC is the default for x86_64. */
if (TARGET_MACHO TARGET_64BIT)
@@ -7052,6 +7061,27 @@ ix86_function_value (const_tree valtype,
const_tree fntype_or_decl,
return ix86_function_value_1 (valtype, fntype_or_decl, orig_mode, mode);
}
+/* Pointer function arguments and return values are promoted to Pmode.
+ If FOR_RETURN is 1, this function must behave in the same way with
+ regard to function returns as TARGET_FUNCTION_VALUE. */
+
+static enum machine_mode
+ix86_promote_function_mode (const_tree type, enum machine_mode mode,
+ int *punsignedp, const_tree fntype,
+ int for_return)
+{
+ if (for_return == 1)
+/* Do not promote function return values. */
+;
+ else if (type != NULL_TREE POINTER_TYPE_P (type))
+{
+ *punsignedp = POINTERS_EXTEND_UNSIGNED;
+ return Pmode;
+}
+ return default_promote_function_mode (type, mode, punsignedp, fntype,
+ for_return);
+}
+
rtx
ix86_libcall_value (enum machine_mode mode)
{
@@ -34810,6 +35157,9 @@ ix86_autovectorize_vector_sizes (void)
#undef TARGET_FUNCTION_VALUE_REGNO_P
#define TARGET_FUNCTION_VALUE_REGNO_P ix86_function_value_regno_p
+#undef TARGET_PROMOTE_FUNCTION_MODE
+#define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
+
#undef TARGET_SECONDARY_RELOAD
#define TARGET_SECONDARY_RELOAD ix86_secondary_reload
[Patch, Fortran] Support allocatable *scalar* coarrays
This patch implemented the trans*.c part of allocatable scalar coarrays;
contrary to noncoarray allocatable scalars, they have cobounds and thus
use an array descriptor.
While there are still some bugs and minor omissions, gfortran slowly
gets feature compile with regards to single-image coarrays support.
Still to be done: Fixes to LOCK_TYPE constraint checks, polymorphic
coarrays, some issues with coarray dummies, some issues with allocatable
coarray components.
The patch also works with -fcoarray=lib. However, the to-do list for
libcaf is much longer. On the front-end side, there are additional
issues with argument passing, deallocate, some minor allocate issues
(token), and in particular calling the library for actual
communication, for locking and for atomic access. Additionally, the
message-processing loop in the library is still missing.
The attached patch was build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2011-07-10 Tobias Burnus bur...@net-b.de
* expr.c (gfc_ref_this_image): New function.
(gfc_is_coindexed): Use it.
* gfortran.h (gfc_ref_this_image): New prototype.
* resolve.c (resolve_deallocate_expr,
resolve_allocate_expr): Support alloc scalar coarrays.
* trans-array.c (gfc_conv_array_ref, gfc_array_init_size,
gfc_conv_descriptor_cosize, gfc_array_allocate,
gfc_trans_deferred_array): Ditto.
* trans-expr.c (gfc_conv_variable) Ditto.:
* trans-stmt.c (gfc_trans_deallocate): Ditto.
* trans-types.c (gfc_get_element_type, gfc_get_array_type_bounds
gfc_get_array_descr_info): Ditto.
2011-07-10 Tobias Burnus bur...@net-b.de
* gfortran.dg/coarray_14.f90: Remove dg-error sorry not implemented.
* gfortran.dg/coarray_7.f90: Ditto.
* gfortran.dg/coarray/scalar_alloc_1.f90: New.
* gfortran.dg/coarray/scalar_alloc_2.f90: New.
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 6db0836..3bf1e94 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4126,18 +4126,28 @@ gfc_expr_replace_comp (gfc_expr *expr, gfc_component *dest)
bool
+gfc_ref_this_image (gfc_ref *ref)
+{
+ int n;
+
+ gcc_assert (ref-type == REF_ARRAY ref-u.ar.codimen 0);
+
+ for (n = ref-u.ar.dimen; n ref-u.ar.dimen + ref-u.ar.codimen; n++)
+if (ref-u.ar.dimen_type[n] != DIMEN_THIS_IMAGE)
+ return false;
+
+ return true;
+}
+
+
+bool
gfc_is_coindexed (gfc_expr *e)
{
gfc_ref *ref;
for (ref = e-ref; ref; ref = ref-next)
if (ref-type == REF_ARRAY ref-u.ar.codimen 0)
- {
- int n;
- for (n = ref-u.ar.dimen; n ref-u.ar.dimen + ref-u.ar.codimen; n++)
- if (ref-u.ar.dimen_type[n] != DIMEN_THIS_IMAGE)
- return true;
- }
+ return !gfc_ref_this_image (ref);
return false;
}
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 328dfbe..eb01b0e 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2733,6 +2733,7 @@ void gfc_expr_replace_comp (gfc_expr *, gfc_component *);
bool gfc_is_proc_ptr_comp (gfc_expr *, gfc_component **);
+bool gfc_ref_this_image (gfc_ref *ref);
bool gfc_is_coindexed (gfc_expr *);
int gfc_get_corank (gfc_expr *);
bool gfc_has_ultimate_allocatable (gfc_expr *);
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index b51ae96..07104b8 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -6460,7 +6460,9 @@ resolve_deallocate_expr (gfc_expr *e)
switch (ref-type)
{
case REF_ARRAY:
- if (ref-u.ar.type != AR_FULL)
+ if (ref-u.ar.type != AR_FULL
+ !(ref-u.ar.type == AR_ELEMENT ref-u.ar.as-rank == 0
+ ref-u.ar.codimen gfc_ref_this_image (ref)))
allocatable = 0;
break;
@@ -6983,13 +6985,6 @@ check_symbols:
goto failure;
}
- if (codimension ar-as-rank == 0)
-{
- gfc_error (Sorry, allocatable scalar coarrays are not yet supported
- at %L, e-where);
- goto failure;
-}
-
success:
return SUCCESS;
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index f4f79f9..4ec892b 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -2623,12 +2623,20 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * ar, gfc_symbol * sym,
if (ar-dimen == 0)
{
gcc_assert (ar-codimen);
- if (GFC_ARRAY_TYPE_P (TREE_TYPE (se-expr))
- TREE_CODE (TREE_TYPE (se-expr)) == POINTER_TYPE)
- se-expr = build_fold_indirect_ref_loc (input_location, se-expr);
- /* Use the actual tree type and not the wrapped coarray. */
- se-expr = fold_convert (TYPE_MAIN_VARIANT (TREE_TYPE (se-expr)), se-expr);
+ if (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se-expr)))
+ se-expr = build_fold_indirect_ref (gfc_conv_array_data (se-expr));
+ else
+ {
+ if (GFC_ARRAY_TYPE_P (TREE_TYPE (se-expr))
+ TREE_CODE (TREE_TYPE (se-expr)) == POINTER_TYPE)
+ se-expr = build_fold_indirect_ref_loc (input_location, se-expr);
+
+ /* Use the actual tree type and not the wrapped coarray. */
+ se-expr = fold_convert (TYPE_MAIN_VARIANT (TREE_TYPE (se-expr)),
+
Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant
On Sun, Jul 10, 2011 at 9:36 AM, Paolo Bonzini bonz...@gnu.org wrote:
On Sat, Jul 9, 2011 at 23:31, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini bonz...@gnu.org wrote:
On 07/05/2011 04:27 PM, H.J. Lu wrote:
diff --git a/gcc/explow.c b/gcc/explow.c
index 7387dad..b343bf8 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -383,18 +383,13 @@ convert_memory_address_addr_space (enum
machine_mode to_mode ATTRIBUTE_UNUSED,
case PLUS:
case MULT:
- /* For addition we can safely permute the conversion and addition
- operation if one operand is a constant and converting the
constant
- does not change it or if one operand is a constant and we are
- using a ptr_extend instruction (POINTERS_EXTEND_UNSIGNED 0).
- We can always safely permute them if we are making the address
- narrower. */
+ /* For addition we safely permute the conversion and addition
+ operation if one operand is a constant since we can't generate
+ new instructions. We can always safely permute them if we are
+ making the address narrower. */
if (GET_MODE_SIZE (to_mode) GET_MODE_SIZE (from_mode)
|| (GET_CODE (x) == PLUS
- CONST_INT_P (XEXP (x, 1))
- (XEXP (x, 1) == convert_memory_address_addr_space
- (to_mode, XEXP (x, 1), as)
- || POINTERS_EXTEND_UNSIGNED 0)))
+ CONST_INT_P (XEXP (x, 1
return gen_rtx_fmt_ee (GET_CODE (x), to_mode,
convert_memory_address_addr_space
(to_mode, XEXP (x, 0), as),
This does not seem safe to me.
The current code is broken for x32. See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47727
We can't generate any new instructions. Do you have any suggestions.
By safe I mean that the new condition might be too wide and generate
wrong code. Richard is definitely right in comment 6, generating new
code in simplify-rtx is a no-no (see its usage of
gen_lowpart_no_emit).
Here is a different approach. I added convert_memory_address_addr_space_1
and convert_modes_1 so that simplify-rtx won't generate new insns. OK
for trunk if there are no regressions on Linux/x86?
Thanks.
--
H.J.
---
2011-07-10 H.J. Lu hongjiu...@intel.com
* explow.c (convert_memory_address_addr_space_1): New.
(convert_memory_address_addr_space): Use it.
* expr.c (convert_modes_1): New.
(convert_modes): Use it.
* expr.h (convert_modes_1): New.
* rtl.h (convert_memory_address_addr_space_1): New.
(convert_memory_address_1): Likewise.
* simplify-rtx.c (simplify_unary_operation_1): Call
convert_memory_address_1 instead of convert_memory_address.
2011-07-10 H.J. Lu hongjiu...@intel.com
* explow.c (convert_memory_address_addr_space_1): New.
(convert_memory_address_addr_space): Use it.
* expr.c (convert_modes_1): New.
(convert_modes): Use it.
* expr.h (convert_modes_1): New.
* rtl.h (convert_memory_address_addr_space_1): New.
(convert_memory_address_1): Likewise.
* simplify-rtx.c (simplify_unary_operation_1): Call
convert_memory_address_1 instead of convert_memory_address.
diff --git a/gcc/explow.c b/gcc/explow.c
index 3c692f4..ee52e92 100644
--- a/gcc/explow.c
+++ b/gcc/explow.c
@@ -320,8 +320,9 @@ break_out_memory_refs (rtx x)
arithmetic insns can be used. */
rtx
-convert_memory_address_addr_space (enum machine_mode to_mode ATTRIBUTE_UNUSED,
- rtx x, addr_space_t as ATTRIBUTE_UNUSED)
+convert_memory_address_addr_space_1 (enum machine_mode to_mode
ATTRIBUTE_UNUSED,
+rtx x, addr_space_t as ATTRIBUTE_UNUSED,
+bool no_emit ATTRIBUTE_UNUSED)
{
#ifndef POINTERS_EXTEND_UNSIGNED
gcc_assert (GET_MODE (x) == to_mode || GET_MODE (x) == VOIDmode);
@@ -406,10 +407,17 @@ convert_memory_address_addr_space (enum machine_mode
to_mode ATTRIBUTE_UNUSED,
break;
}
- return convert_modes (to_mode, from_mode,
- x, POINTERS_EXTEND_UNSIGNED);
+ return convert_modes_1 (to_mode, from_mode, x,
+ POINTERS_EXTEND_UNSIGNED, no_emit);
#endif /* defined(POINTERS_EXTEND_UNSIGNED) */
}
+
+rtx
+convert_memory_address_addr_space (enum machine_mode to_mode,
+ rtx x, addr_space_t as)
+{
+ return convert_memory_address_addr_space_1 (to_mode, x, as, false);
+}
/* Return something equivalent to X but valid as a memory address for something
of mode MODE in the named address space AS. When X is not itself valid,
diff --git a/gcc/expr.c b/gcc/expr.c
index fb4379f..de7f150 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -693,13 +693,16 @@ convert_to_mode (enum machine_mode mode, rtx x, int
unsignedp)
Both
Re: [rfc, i386] Convert output_mi_thunk to rtl
On 07/10/2011 02:33 AM, Uros Bizjak wrote:
+ reload_completed = 1;
+ epilogue_completed = 1;
Do we really need these? Perhaps a comment should be added here, it is
not obvious at the first sight...
We didn't need these. ia64 did because there we run a split pass
to properly generate the call patterns.
Here's the patch I re-tested and committed.
r~
* config/i386/i386.c (x86_output_mi_thunk): Generate rtl and
run final, instead of emitting text directly.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index f3fd0db..f948a32 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -29296,12 +29296,10 @@ x86_output_mi_thunk (FILE *file,
tree thunk ATTRIBUTE_UNUSED, HOST_WIDE_INT delta,
HOST_WIDE_INT vcall_offset, tree function)
{
- rtx xops[3];
rtx this_param = x86_this_parameter (function);
- rtx this_reg, tmp;
+ rtx this_reg, tmp, fnaddr;
- /* Make sure unwind info is emitted for the thunk if needed. */
- final_start_function (emit_barrier (), file, 1);
+ emit_note (NOTE_INSN_PROLOGUE_END);
/* If VCALL_OFFSET, we'll need THIS in a register. Might as well
pull it in now and let DELTA benefit. */
@@ -29310,9 +29308,8 @@ x86_output_mi_thunk (FILE *file,
else if (vcall_offset)
{
/* Put the this parameter into %eax. */
- xops[0] = this_param;
- xops[1] = this_reg = gen_rtx_REG (Pmode, AX_REG);
- output_asm_insn (mov%z1\t{%0, %1|%1, %0}, xops);
+ this_reg = gen_rtx_REG (Pmode, AX_REG);
+ emit_move_insn (this_reg, this_param);
}
else
this_reg = NULL_RTX;
@@ -29320,116 +29317,121 @@ x86_output_mi_thunk (FILE *file,
/* Adjust the this parameter by a fixed constant. */
if (delta)
{
- xops[0] = GEN_INT (delta);
- xops[1] = this_reg ? this_reg : this_param;
+ rtx delta_rtx = GEN_INT (delta);
+ rtx delta_dst = this_reg ? this_reg : this_param;
+
if (TARGET_64BIT)
{
- if (!x86_64_general_operand (xops[0], DImode))
+ if (!x86_64_general_operand (delta_rtx, Pmode))
{
- tmp = gen_rtx_REG (DImode, R10_REG);
- xops[1] = tmp;
- output_asm_insn (mov{q}\t{%1, %0|%0, %1}, xops);
- xops[0] = tmp;
- xops[1] = this_param;
+ tmp = gen_rtx_REG (Pmode, R10_REG);
+ emit_move_insn (tmp, delta_rtx);
+ delta_rtx = tmp;
}
- if (x86_maybe_negate_const_int (xops[0], DImode))
- output_asm_insn (sub{q}\t{%0, %1|%1, %0}, xops);
- else
- output_asm_insn (add{q}\t{%0, %1|%1, %0}, xops);
}
- else if (x86_maybe_negate_const_int (xops[0], SImode))
- output_asm_insn (sub{l}\t{%0, %1|%1, %0}, xops);
- else
- output_asm_insn (add{l}\t{%0, %1|%1, %0}, xops);
+
+ emit_insn (ix86_gen_add3 (delta_dst, delta_dst, delta_rtx));
}
/* Adjust the this parameter by a value stored in the vtable. */
if (vcall_offset)
{
+ rtx vcall_addr, vcall_mem;
+ unsigned int tmp_regno;
+
if (TARGET_64BIT)
- tmp = gen_rtx_REG (DImode, R10_REG);
+ tmp_regno = R10_REG;
else
{
- int tmp_regno = CX_REG;
unsigned int ccvt = ix86_get_callcvt (TREE_TYPE (function));
if ((ccvt (IX86_CALLCVT_FASTCALL | IX86_CALLCVT_THISCALL)) != 0)
tmp_regno = AX_REG;
- tmp = gen_rtx_REG (SImode, tmp_regno);
+ else
+ tmp_regno = CX_REG;
}
+ tmp = gen_rtx_REG (Pmode, tmp_regno);
- xops[0] = gen_rtx_MEM (Pmode, this_reg);
- xops[1] = tmp;
- output_asm_insn (mov%z1\t{%0, %1|%1, %0}, xops);
+ emit_move_insn (tmp, gen_rtx_MEM (ptr_mode, this_reg));
/* Adjust the this parameter. */
- xops[0] = gen_rtx_MEM (Pmode, plus_constant (tmp, vcall_offset));
- if (TARGET_64BIT !memory_operand (xops[0], Pmode))
+ vcall_addr = plus_constant (tmp, vcall_offset);
+ if (TARGET_64BIT
+ !ix86_legitimate_address_p (ptr_mode, vcall_addr, true))
{
- rtx tmp2 = gen_rtx_REG (DImode, R11_REG);
- xops[0] = GEN_INT (vcall_offset);
- xops[1] = tmp2;
- output_asm_insn (mov{q}\t{%0, %1|%1, %0}, xops);
- xops[0] = gen_rtx_MEM (Pmode, gen_rtx_PLUS (Pmode, tmp, tmp2));
+ rtx tmp2 = gen_rtx_REG (Pmode, R11_REG);
+ emit_move_insn (tmp2, GEN_INT (vcall_offset));
+ vcall_addr = gen_rtx_PLUS (Pmode, tmp, tmp2);
}
- xops[1] = this_reg;
- output_asm_insn (add%z1\t{%0, %1|%1, %0}, xops);
+
+ vcall_mem = gen_rtx_MEM (Pmode, vcall_addr);
+ emit_insn (ix86_gen_add3 (this_reg, this_reg, vcall_mem));
}
/* If necessary, drop THIS back to its stack slot. */
if (this_reg this_reg != this_param)
-{
- xops[0] = this_reg;
- xops[1] = this_param;
- output_asm_insn (mov%z1\t{%0, %1|%1, %0}, xops);
-}
+
Re: PATCH [5/n] X32: Fix x32 trampoline
On 07/10/2011 12:45 PM, H.J. Lu wrote: * config/i386/i386.c (ix86_trampoline_init): Use movl instead of movabs for x32. Ok. r~
Re: PATCH [3/n] X32: Promote pointers to Pmode
On 07/10/2011 12:43 PM, H.J. Lu wrote:
+/* Pointer function arguments and return values are promoted to Pmode.
+ If FOR_RETURN is 1, this function must behave in the same way with
+ regard to function returns as TARGET_FUNCTION_VALUE. */
+
+static enum machine_mode
+ix86_promote_function_mode (const_tree type, enum machine_mode mode,
+ int *punsignedp, const_tree fntype,
+ int for_return)
+{
+ if (for_return == 1)
+/* Do not promote function return values. */
+;
+ else if (type != NULL_TREE POINTER_TYPE_P (type))
These two comments still conflict. And why wouldn't you want to
promote return values?
r~
Re: PATCH [3/n] X32: Promote pointers to Pmode
On Sun, Jul 10, 2011 at 5:48 PM, Richard Henderson r...@redhat.com wrote: On 07/10/2011 03:01 PM, H.J. Lu wrote: We only want to promote function parameters passed/returned in register. But I can't tell if a value will be passed in register or memory inside of TARGET_FUNCTION_VALUE. So when FOR_RETURN is 1, we don't promote. Even if we don't promote it explicitly, hardware still zero-extends it for us. So it isn't a real issue. The hardware *usually* zero-extends. It all depends on where the data is coming from. Without certainty, i.e. actually representing it properly, you're designing a broken ABI. What you wrote above re T_F_V not being able to tell register or memory doesn't make sense. Did you really mean inside TARGET_PROMOTE_FUNCTION_MODE? And why exactly wouldn't you be able to tell there? Can you not find out via a call to ix86_return_in_memory? TARGET_PROMOTE_FUNCTION_MODE is for passing/returning value in a register and the documentation says that: FOR_RETURN allows to distinguish the promotion of arguments and return values. If it is `1', a return value is being promoted and `TARGET_FUNCTION_VALUE' must perform the same promotions done here. If it is `2', the returned mode should be that of the register in which an incoming parameter is copied, or the outgoing result is computed; then the hook should return the same mode as `promote_mode', though the signedness may be different. But for TARGET_FUNCTION_VALUE, there is no difference for register and memory. That is why I don't promote when FOR_RETURN is 1. mmix/mmix.c and rx/rx.c have similar treatment. -- H.J.
Re: PATCH [4/n] X32: Use ptr_mode for vtable adjustment
On Sat, Jul 9, 2011 at 3:58 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Sat, Jul 9, 2011 at 3:43 PM, Richard Henderson r...@redhat.com wrote:
On 07/09/2011 02:36 PM, H.J. Lu wrote:
Hi,
Thunk is in ptr_mode, not Pmode. OK for trunk?
Thanks.
H.J.
---
2011-07-09 H.J. Lu hongjiu...@intel.com
* config/i386/i386.c (x86_output_mi_thunk): Use ptr_mode instead
of Pmode for vtable adjustment.
Not ok. This is incoherent in its treatment of Pmode vs ptr_mode.
You're creating an addition
(plus:P (reg:ptr tmp) (reg:P tmp2))
It is because thunk is stored in ptr_mode, not Pmode.
I have a queued patch that replaces all of this with rtl. I will
post it later today.
I will update it for x32 after your change is checked in.
I am testing this updated patch. OK for trunk if it works?
Thanks.
--
H.J.
---
2011-07-10 H.J. Lu hongjiu...@intel.com
* config/i386/i386.c (x86_output_mi_thunk): Support ptr_mode
!= Pmode.
* config/i386/i386.md (*addsi_1_zext): Renamed to ...
(addsi_1_zext): This.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a46101b..d6744be 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -29346,7 +29673,7 @@ x86_output_mi_thunk (FILE *file,
/* Adjust the this parameter by a value stored in the vtable. */
if (vcall_offset)
{
- rtx vcall_addr, vcall_mem;
+ rtx vcall_addr, vcall_mem, this_mem;
unsigned int tmp_regno;
if (TARGET_64BIT)
@@ -29361,7 +29688,10 @@ x86_output_mi_thunk (FILE *file,
}
tmp = gen_rtx_REG (Pmode, tmp_regno);
- emit_move_insn (tmp, gen_rtx_MEM (ptr_mode, this_reg));
+ this_mem = gen_rtx_MEM (ptr_mode, this_reg);
+ if (Pmode == DImode ptr_mode == SImode)
+ this_mem = gen_rtx_ZERO_EXTEND (DImode, this_mem);
+ emit_move_insn (tmp, this_mem);
/* Adjust the this parameter. */
vcall_addr = plus_constant (tmp, vcall_offset);
@@ -29373,8 +29703,13 @@ x86_output_mi_thunk (FILE *file,
vcall_addr = gen_rtx_PLUS (Pmode, tmp, tmp2);
}
- vcall_mem = gen_rtx_MEM (Pmode, vcall_addr);
- emit_insn (ix86_gen_add3 (this_reg, this_reg, vcall_mem));
+ vcall_mem = gen_rtx_MEM (ptr_mode, vcall_addr);
+ if (Pmode == DImode ptr_mode == SImode)
+ emit_insn (gen_addsi_1_zext (this_reg,
+gen_rtx_REG (SImode, REGNO (this_reg)),
+vcall_mem));
+ else
+ emit_insn (ix86_gen_add3 (this_reg, this_reg, vcall_mem));
}
/* If necessary, drop THIS back to its stack slot. */
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index a52941b..3136fd0 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -5508,11 +5574,11 @@
;; operands so proper swapping will be done in reload. This allow
;; patterns constructed from addsi_1 to match.
-(define_insn *addsi_1_zext
+(define_insn addsi_1_zext
[(set (match_operand:DI 0 register_operand =r,r,r)
(zero_extend:DI
(plus:SI (match_operand:SI 1 nonimmediate_operand %0,r,r)
(match_operand:SI 2 general_operand g,0,li
(clobber (reg:CC FLAGS_REG))]
TARGET_64BIT ix86_binary_operator_ok (PLUS, SImode, operands)
{
Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant
On Sun, Jul 10, 2011 at 5:04 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Jul 10, 2011 at 4:51 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Jul 10, 2011 at 2:04 PM, H.J. Lu hjl.to...@gmail.com wrote: On Sun, Jul 10, 2011 at 9:36 AM, Paolo Bonzini bonz...@gnu.org wrote: On Sat, Jul 9, 2011 at 23:31, H.J. Lu hjl.to...@gmail.com wrote: On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini bonz...@gnu.org wrote: On 07/05/2011 04:27 PM, H.J. Lu wrote: diff --git a/gcc/explow.c b/gcc/explow.c index 7387dad..b343bf8 100644 --- a/gcc/explow.c +++ b/gcc/explow.c @@ -383,18 +383,13 @@ convert_memory_address_addr_space (enum machine_mode to_mode ATTRIBUTE_UNUSED, case PLUS: case MULT: - /* For addition we can safely permute the conversion and addition - operation if one operand is a constant and converting the constant - does not change it or if one operand is a constant and we are - using a ptr_extend instruction (POINTERS_EXTEND_UNSIGNED 0). - We can always safely permute them if we are making the address - narrower. */ + /* For addition we safely permute the conversion and addition + operation if one operand is a constant since we can't generate + new instructions. We can always safely permute them if we are + making the address narrower. */ if (GET_MODE_SIZE (to_mode) GET_MODE_SIZE (from_mode) || (GET_CODE (x) == PLUS - CONST_INT_P (XEXP (x, 1)) - (XEXP (x, 1) == convert_memory_address_addr_space - (to_mode, XEXP (x, 1), as) - || POINTERS_EXTEND_UNSIGNED 0))) + CONST_INT_P (XEXP (x, 1 return gen_rtx_fmt_ee (GET_CODE (x), to_mode, convert_memory_address_addr_space (to_mode, XEXP (x, 0), as), This does not seem safe to me. The current code is broken for x32. See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47727 We can't generate any new instructions. Do you have any suggestions. By safe I mean that the new condition might be too wide and generate wrong code. Richard is definitely right in comment 6, generating new code in simplify-rtx is a no-no (see its usage of gen_lowpart_no_emit). Here is a different approach. I added convert_memory_address_addr_space_1 and convert_modes_1 so that simplify-rtx won't generate new insns. OK for trunk if there are no regressions on Linux/x86? Thanks. -- H.J. --- 2011-07-10 H.J. Lu hongjiu...@intel.com * explow.c (convert_memory_address_addr_space_1): New. (convert_memory_address_addr_space): Use it. * expr.c (convert_modes_1): New. (convert_modes): Use it. * expr.h (convert_modes_1): New. * rtl.h (convert_memory_address_addr_space_1): New. (convert_memory_address_1): Likewise. * simplify-rtx.c (simplify_unary_operation_1): Call convert_memory_address_1 instead of convert_memory_address. It doesn't work. I got (gdb) f 2 #2 0x0078735a in convert_memory_address_addr_space_1 (to_mode=DImode, x=0x705ac4e0, as=0 '\000', no_emit=1 '\001') at /export/gnu/import/git/gcc-x32/gcc/explow.c:410 410 return convert_modes_1 (to_mode, from_mode, x, (gdb) call debug_rtx (x) (plus:SI (symbol_ref:SI (iplane.1577) [flags 0x2] var_decl 0x70857960 iplane) (const_int -4 [0xfffc])) (gdb) bt #0 fancy_abort (file=0x13531a8 /export/gnu/import/git/gcc-x32/gcc/expr.c, line=798, function=0x1354a00 convert_modes_1) at /export/gnu/import/git/gcc-x32/gcc/diagnostic.c:893 #1 0x0079c60c in convert_modes_1 (mode=DImode, oldmode=SImode, x=0x705ac4e0, unsignedp=1, no_emit=1 '\001') at /export/gnu/import/git/gcc-x32/gcc/expr.c:798 #2 0x0078735a in convert_memory_address_addr_space_1 (to_mode=DImode, x=0x705ac4e0, as=0 '\000', no_emit=1 '\001') at /export/gnu/import/git/gcc-x32/gcc/explow.c:410 #3 0x00787281 in convert_memory_address_addr_space_1 (to_mode=DImode, x=0x705616d0, as=0 '\000', no_emit=1 '\001') at /export/gnu/import/git/gcc-x32/gcc/explow.c:381 #4 0x00b0faf4 in simplify_unary_operation_1 (code=ZERO_EXTEND, mode=DImode, op=0x705616d0) at /export/gnu/import/git/gcc-x32/gcc/simplify-rtx.c:1246 #5 0x00b0d851 in simplify_unary_operation (code=ZERO_EXTEND, mode=DImode, op=0x705616d0, op_mode=SImode) at /export/gnu/import/git/gcc-x32/gcc/simplify-rtx.c:582 #6 0x00b0d035 in simplify_gen_unary (code=ZERO_EXTEND, mode=DImode, op=0x705616d0, op_mode=SImode) at /export/gnu/import/git/gcc-x32/gcc/simplify-rtx.c:370 #7 0x0117078a in if_then_else_cond (x=0x702ebb00, ptrue=0x7fffd720, pfalse=0x7fffd718) ---Type return to continue, or q return to quit--- at
Re: RFA: Making attribute values avaliable for options
Quoting Joseph S. Myers jos...@codesourcery.com:
On Tue, 5 Jul 2011, Joern Rennecke wrote:
This patch splits out a new generator genattr-enum from genattr, and it
generates insn-attr-enum.h, which just makes the enum declarations.
This new header file is then included by options.c and insn-attr.h .
Is there a particular reason for making this separate from the existing
genattr-common that I created recently? Like opts.c, options.c is a file
shared by both the driver and the core compiler that can't include the
full insn-attr.h for the same reason.
Attached is a variant of my patch that uses your suggestion.
bootstrapped on x86_64-unknown-linux-gnu.
2011-07-11 Joern Rennecke joern.renne...@embecosm.com
* genattr.c (write_upcase, gen_attr enum definition writing):
Move to ...
* genattr-common.c ... here.
(main): Call gen_attr.
* optc-gen.awk: Make generated program include insn-attr-common.h .
* Makefile.in (oprions.o): Depend on insn-attr-common.h
Index: gcc/genattr-common.c
===
--- gcc/genattr-common.c(revision 175852)
+++ gcc/genattr-common.c(working copy)
@@ -30,6 +30,36 @@ Software Foundation; either version 3, o
#include read-md.h
#include gensupport.h
+static void
+write_upcase (const char *str)
+{
+ for (; *str; str++)
+putchar (TOUPPER(*str));
+}
+
+static void
+gen_attr (rtx attr)
+{
+ const char *p, *tag;
+
+ p = XSTR (attr, 1);
+ if (*p != '\0')
+{
+ printf (enum attr_%s {, XSTR (attr, 0));
+
+ while ((tag = scan_comma_elt (p)) != 0)
+ {
+ write_upcase (XSTR (attr, 0));
+ putchar ('_');
+ while (tag != p)
+ putchar (TOUPPER (*tag++));
+ if (*p == ',')
+ fputs (, , stdout);
+ }
+ fputs (};\n, stdout);
+}
+}
+
int
main (int argc, char **argv)
{
@@ -57,6 +87,9 @@ main (int argc, char **argv)
if (desc == NULL)
break;
+ if (GET_CODE (desc) == DEFINE_ATTR)
+ gen_attr (desc);
+
if (GET_CODE (desc) == DEFINE_DELAY)
{
if (!have_delay)
Index: gcc/genattr.c
===
--- gcc/genattr.c (revision 175852)
+++ gcc/genattr.c (working copy)
@@ -30,23 +30,15 @@ Software Foundation; either version 3, o
#include gensupport.h
-static void write_upcase (const char *);
static void gen_attr (rtx);
-static void
-write_upcase (const char *str)
-{
- for (; *str; str++)
-putchar (TOUPPER(*str));
-}
-
static VEC (rtx, heap) *const_attrs, *reservations;
static void
gen_attr (rtx attr)
{
- const char *p, *tag;
+ const char *p;
int is_const = GET_CODE (XEXP (attr, 2)) == CONST;
if (is_const)
@@ -65,23 +57,8 @@ gen_attr (rtx attr)
printf (extern int get_attr_%s (%s);\n, XSTR (attr, 0),
(is_const ? void : rtx));
else
- {
- printf (enum attr_%s {, XSTR (attr, 0));
-
- while ((tag = scan_comma_elt (p)) != 0)
- {
- write_upcase (XSTR (attr, 0));
- putchar ('_');
- while (tag != p)
- putchar (TOUPPER (*tag++));
- if (*p == ',')
- fputs (, , stdout);
- }
- fputs (};\n, stdout);
-
- printf (extern enum attr_%s get_attr_%s (%s);\n\n,
- XSTR (attr, 0), XSTR (attr, 0), (is_const ? void : rtx));
- }
+ printf (extern enum attr_%s get_attr_%s (%s);\n\n,
+ XSTR (attr, 0), XSTR (attr, 0), (is_const ? void : rtx));
}
/* If `length' attribute, write additional function definitions and define
Index: gcc/optc-gen.awk
===
--- gcc/optc-gen.awk(revision 175852)
+++ gcc/optc-gen.awk(working copy)
@@ -37,6 +37,7 @@ for (i = 1; i = n_headers; i++)
print #include quote headers[i] quote
print #include quote opts.h quote
print #include quote intl.h quote
+print #include quote insn-attr-common.h quote
print
if (n_extra_c_includes 0) {
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 175852)
+++ gcc/Makefile.in (working copy)
@@ -2311,7 +2311,7 @@ s-options-h: optionlist $(srcdir)/opt-fu
$(STAMP) $@
options.o: options.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
- $(TM_H) $(OPTS_H) intl.h $(OPTIONS_C_EXTRA)
+ $(TM_H) $(OPTS_H) intl.h $(OPTIONS_C_EXTRA) insn-attr-common.h
options-save.o: options-save.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TARGET_H)
$(FLAGS_H) \
$(TM_H) $(OPTS_H) intl.h $(OPTIONS_C_EXTRA)
