Re: typo in gcc-4.4 changes
On 06/04/2009, Gerald Pfeifer wrote: > On Sat, 4 Apr 2009, Jonathan Wakely wrote: >> There is currently no way to get from the front page to the >> gcc-4.4/changes.html page, should there be a "(changes)" link on the >> front page until a release is added to the gcc-4.4/index.html page? > > I think that would be appropriate, yes. Are you going to make this > change? Should I undo this change to the front page, now that the 'changes' link is next to the 4.4.0 release on gcc-4.4/index.html ? Jonathan
[gSoc] [graphite] general plan for Automatic parallelization in Graphite
Hi, It's nice that the proposal 'Automatic parallelization in Graphite' is accepted. Which means I will be working with great Graphtie developers this summer, and trying to implement the project . I have set up a blog for this project, which will mainly about this project: 1. plans 2. what I have done 3. related Graphite internals You can subscribe to it if you like: http://summergraphite.blogspot.com/ Here is a general plan for this project, keep you in loop, and feel free to comment :) 1. Mark the innermost loop parallel [done] 2. Try to schedule autopar pass after Graphite, and enable code generation if flag_graphite_force_parallel is set - There should be some discussion with Razya about her plan about the autopar part - But before that, I'll try to schedule autopar first 3. I may try to write testcases for the loops that should be parallel, from simple to hard, and check autopar's code generation part, make sure this works correctly as we expected. - The testcases is important. There should be some detailed discussion maybe with Sebastian and Konrad. To see what kind of loop we can/decide to handle. - Check autopar's code generation with flag_graphite_force_parallel set with these testcases, report bugs if it goes wrong. 4. Try to write code for deciding if a loop can be parallel with data dependency test under this polyhedral model. - Try to understand the interface of data dependency test - Write code, if data dependency success, mark the loop parallel Cheers, Li
Urgent Question regarding GCOV
Hello GCC Experts,
I am an engineer trying to run gcov for our unit tests. We have a couple of
DLLs and a few static libraries.
I am having trouble linking the Test program that links in the DLLs. I have
the following in the Cmake files:
IF( "${COVERAGE}" STREQUAL "TRUE" )
LINK_DIRECTORIES(/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3)
TARGET_LINK_LIBRARIES( NWATest analytics TestUtils ${SYSTEM_LIBS} )
ENDIF( "${COVERAGE}" STREQUAL "TRUE" )
I have similar lines for all make files that create TARGET_LINK_LIBRARIES.
But I get the following errors:
/bin/ld: NWATest: hidden symbol `__gcov_init' in
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/libgcc.a(_gcov.oS) is referenced by
DSO
COULD SOMEONE PLEASE HELP!!! I have not found ANY ONLINE documentation or
solutions on message boards.
Many Thanks.PLEASE SEE MORE INFO BELOW.
Jayashree
Below is the last cmd line that was executed: I have provided some info on
uname etc...
/usr/bin/c++ -Wall -fPIC -m64 -DLINUX -fprofile-arcs -ftest-coverage -D_DEBUG
-ggdb3 -fPIC "CMakeFiles/NWATest.dir/nwaTest.o" -o NWATest -rdynamic
-L/mnt/releases/icu4c/gnr/latest/sles9_64-gcc33-debug/lib
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/nameworks/analytics
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/test-utils
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/nameworks/common
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/parser
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/classifier
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/analyzer
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/nvg
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/genderizer
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/coa_plus/nc_coa
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/coa_plus/coa
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/transliterator
-L/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/sifter -lanalytics
-Wl,-Bstatic -lTestUtils -Wl,-Bdynamic -lpthread -ldl -Wl,-Bstatic -lISShared
-lNameParser -lNameClassifier -lNameAnalyzer -lNameVariantGenerator
-lNameGenderizer -lNC_COA -lCOA -lNameTransliterator -lNameSifter -Wl,-Bdynamic
-lsicui18n -lsicuuc -lsicudata
-Wl,-rpath,/mnt/releases/icu4c/gnr/latest/sles9_64-gcc33-debug/lib:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/nameworks/analytics:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/test-utils:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/nameworks/common:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/parser:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/classifier:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/analyzer:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/nvg:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/genderizer:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/coa_plus/nc_coa:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/coa_plus/coa:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/transliterator:/home/jramani/CMake/cb_bugs0809/sles9_64-gcc33-debug/sifter
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/../../../../x86_64-suse-linux/bin/ld:
NWATest: hidden symbol `__gcov_init' in
/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/libgcc.a(_gcov.oS) is referenced by
DSO
collect2: ld returned 1 exit status
make[2]: *** [nameworks/testing/NWATest] Error 1
~/sles9_64-gcc33-debug$ uname -a
Linux lnxdev9 2.6.5-7.244-smp #1 SMP Mon Dec 12 18:32:25 UTC 2005 x86_64 x86_64
x86_64 GNU/Linux
~/sles9_64-gcc33-debug$ which gcc
/usr/bin/gcc
~/sles9_64-gcc33-debug$ which gcov
/usr/bin/gcov
Re: Urgent Question regarding GCOV
Jayashree Ramani writes:
> Hello GCC Experts,
This message should have been sent to gcc-h...@gcc.gnu.org rather than
g...@gcc.gnu.org. Please send any followups to gcc-help.
>
> I am an engineer trying to run gcov for our unit tests. We have a couple
> of DLLs and a few static libraries.
>
> I am having trouble linking the Test program that links in the DLLs. I
> have the following in the Cmake files:
>
> IF( "${COVERAGE}" STREQUAL "TRUE" )
> LINK_DIRECTORIES(/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3)
> TARGET_LINK_LIBRARIES( NWATest analytics TestUtils ${SYSTEM_LIBS} )
> ENDIF( "${COVERAGE}" STREQUAL "TRUE" )
gcc 3.3.3 is quite old at this point.
> But I get the following errors:
>
> /bin/ld: NWATest: hidden symbol `__gcov_init' in
> /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/libgcc.a(_gcov.oS) is referenced
> by DSO
The error message means that some shared library is calling __gcov_init,
which is a hidden symbol. The way to fix this is to make sure that you
pass the --coverage option when you link the shared library. At least,
that will do the right thing with current gcc; I don't know for sure
that it will work with gcc 3.3.3.
Ian
Re: Urgent Question regarding GCOV
Thanks Ian. I appreciate your PROMPT response! Wow!
In anycase, I do have followup question. Should I ask you or ask gcc-help?
I have used "-fprofile-arcs -ftest-coverage" options for compilation. Do I
still add --coverage for Linking as LINK_FLAGS?
I will try that whats the latest gcc we should use?
Many Many Thanks!
Jayashree
--- On Wed, 4/22/09, Ian Lance Taylor wrote:
> From: Ian Lance Taylor
> Subject: Re: Urgent Question regarding GCOV
> To: rjayash...@yahoo.com
> Cc: gcc@gcc.gnu.org
> Date: Wednesday, April 22, 2009, 10:41 AM
> Jayashree Ramani writes:
>
> > Hello GCC Experts,
>
> This message should have been sent to gcc-h...@gcc.gnu.org
> rather than
> g...@gcc.gnu.org. Please send any followups to gcc-help.
>
> >
> > I am an engineer trying to run gcov for our unit
> tests. We have a couple of DLLs and a few static libraries.
> >
> > I am having trouble linking the Test program that
> links in the DLLs. I have the following in the Cmake files:
> >
> > IF( "${COVERAGE}" STREQUAL "TRUE"
> )
> >
> LINK_DIRECTORIES(/usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3)
>
> > TARGET_LINK_LIBRARIES( NWATest analytics
> TestUtils ${SYSTEM_LIBS} )
> > ENDIF( "${COVERAGE}" STREQUAL
> "TRUE" )
>
> gcc 3.3.3 is quite old at this point.
>
> > But I get the following errors:
> >
> > /bin/ld: NWATest: hidden symbol `__gcov_init' in
> /usr/lib64/gcc-lib/x86_64-suse-linux/3.3.3/libgcc.a(_gcov.oS)
> is referenced by DSO
>
> The error message means that some shared library is calling
> __gcov_init,
> which is a hidden symbol. The way to fix this is to make
> sure that you
> pass the --coverage option when you link the shared
> library. At least,
> that will do the right thing with current gcc; I don't
> know for sure
> that it will work with gcc 3.3.3.
>
> Ian
Re: [gSoc] [graphite] general plan for Automatic parallelization in Graphite
Are there any plans to move the partial unrolling phase from RTL to Tree-SSA? The move would benefit from better (or easier to implement) Tree-SSA alias analysis. Alex > > > > > --- On Wed, 4/22/09, Li Feng > wrote: > > > From: Li Feng > > Subject: [gSoc] [graphite] general plan for Automatic > parallelization in Graphite > > To: "GCC" > > Cc: "Tobias Grosser" > , "Sebastian" > , "Razya Ladelsky" > , konrad.trifuno...@gmail.com > > Date: Wednesday, April 22, 2009, 5:10 PM > > Hi, > > > > It's nice that the proposal 'Automatic > > parallelization in Graphite' > > is accepted. Which means I will be working with great > > Graphtie > > developers this summer, and trying to implement the > project > > . > > > > I have set up a blog for this project, which will > mainly > > about this > > project: 1. plans 2. what I have done 3. related > Graphite > > internals > > You can subscribe to it if you like: > > http://summergraphite.blogspot.com/ > > > > Here is a general plan for this project, keep you in > loop, > > and feel free to comment :) > > > > 1. Mark the innermost loop parallel [done] > > > > 2. Try to schedule autopar pass after Graphite, and > enable > > code generation if flag_graphite_force_parallel > is set > > - There should be some discussion with Razya > about > >her plan about the autopar part > > - But before that, I'll try to schedule > > autopar first > > > > 3. I may try to write testcases for the loops that > should > > be > > parallel, from simple to hard, and check > autopar's > > code > > generation part, make sure this works correctly > as we > > expected. > > - The testcases is important. There should be > some > >detailed discussion maybe with Sebastian > and > > Konrad. > >To see what kind of loop we can/decide to > > handle. > > - Check autopar's code generation with > >flag_graphite_force_parallel set with these > > testcases, > >report bugs if it goes wrong. > > > > 4. Try to write code for deciding if a loop can be > > parallel > > with data dependency test under this polyhedral > model. > > - Try to understand the interface of data > > dependency test > > - Write code, if data dependency success, mark > the > > loop parallel > > > > Cheers, > > Li
Machine description
Dear all,
I've been working on the Machine description of my target and was
wondering if you could help me out here.
I've been trying to force GCC out of it's habit of generating this code :
(insn 28 8 10 2 glob.c:13 (set (reg:DI 9 r9)
(mem/s:DI (symbol_ref:DI ("data") )
[4 data+0 S8 A64])) 71 {*movdi_internal1} (nil))
-> Load r9, 0(data)
Because, in my target it's costly to do so, I would prefer :
Mov r10, data
Load r9, 0(r10)
This way, GCC can optimize this by taking the first move out of the
loop for example. Otherwise, I have do a final pass but that's too
late for all the optimizations.
My problem is that I've defined the define_expand "movdi" and it only
sees the right case after reload is in progress or completed.
Therefore, I can't create any new pseudos.
Any ideas on how to do this, I've been looking at the other
architectures but haven't seen anything that resembles this,
As always, thanks a lot for your time,
Jc
Restricted version for GCC?
Hi All, I was wondering if gcc had a restricted version which would enable me to write programs with a subset of C language. Any input is much appreciated. Thanks !
Re: Machine description
Jean Christophe Beyler writes:
> I've been working on the Machine description of my target and was
> wondering if you could help me out here.
>
> I've been trying to force GCC out of it's habit of generating this code :
> (insn 28 8 10 2 glob.c:13 (set (reg:DI 9 r9)
> (mem/s:DI (symbol_ref:DI ("data") )
> [4 data+0 S8 A64])) 71 {*movdi_internal1} (nil))
>
> -> Load r9, 0(data)
>
> Because, in my target it's costly to do so, I would prefer :
>
> Mov r10, data
> Load r9, 0(r10)
>
> This way, GCC can optimize this by taking the first move out of the
> loop for example. Otherwise, I have do a final pass but that's too
> late for all the optimizations.
>
> My problem is that I've defined the define_expand "movdi" and it only
> sees the right case after reload is in progress or completed.
> Therefore, I can't create any new pseudos.
>
> Any ideas on how to do this, I've been looking at the other
> architectures but haven't seen anything that resembles this,
This looks somewhat difficcult. I would suggest having the movMM
expander generate the two instruction sequence when can_create_pseudo_p
returns true. Then set the costs so that a load from an address plus an
offset is expensive.
Ian
Re: Restricted version for GCC?
Adayadil Thomas writes: > I was wondering if gcc had a restricted version which would enable me > to write programs > with a subset of C language. This question would be better directed to the gcc-h...@gcc.gnu.org mailing list. Please take any followups to that mailing list. No, gcc does not implement any restricted versions of the C language, except in the sense that you can use warnings and -Werror to effectively disable some dubious constructs. If you send a message to gcc-help about this, I recommend that you describe what sorts of restrictions you had in mind. Ian
Re: Restricted version for GCC?
Adayadil Thomas wrote: Hi All, I was wondering if gcc had a restricted version which would enable me to write programs with a subset of C language. Any input is much appreciated. Thanks ! What are you really looking for here? You can of course use any subset of C you like, and compile and run it using gcc...
Re: messaging
Arthur Schwarz writes:
> In the following code fragment:
>
> # include
> # include
> # include
>
> using namespace std;
> void CommandLine(int argc, char** argv);
> int main(int argc, char** argv) {
>CommandLine(argc, argv[]);
>ifstream x.open(argv[1], ios:in);
>ofstream y.open(argv[1], ios::in);
>
>return 0;
> };
>
> g++-4 messaging is:
>>> g++-4 x.cpp
> x.cpp: In function 'int main(int, char**)':
> x.cpp:8: error: expected primary-expression before ']' token
> x.cpp:10: error: expected primary-expression before ':' token
>
> A recommendation and reason for change is:
> 1: x.cpp:8 error: illegal to pass an array without subscript value as an
>argument
>The given message is accurate but non-expressive of the reason
>for failure.
> 3: cpp:10 error: illegal scope resolution operator ':'
>From memory, there are three uses of ':' in C++
>':' label terminator, :
>':' case in a switch statement, case :
>':' scope resolution operator, "::"
>The given diagnostic message is deceptive.
I filed http://gcc.gnu.org/PR39858 and http://gcc.gnu.org/PR39859 to
track these two issues and to make suggestions for how we can improve
them. Thanks.
Ian
Re: [m32c] IRA reload failures in libstdc++
> I suggest making reload reload the PSImode subreg instead, and
> make the m32c machine description provide for a tertiary
> reload so that the value can be loaded & truncated.
Don't know how to set up a tertiary reload (it's not documented
anywhere).
Is this the type of patch you're thining about? It seems to compile
that problem case, but I haven't tried anything else yet.
Index: config/m32c/m32c.c
===
--- config/m32c/m32c.c (revision 146617)
+++ config/m32c/m32c.c (working copy)
@@ -2040,12 +2040,37 @@ m32c_legitimize_reload_address (rtx * x,
push_reload (XEXP (*x, 0), NULL_RTX, &XEXP (*x, 0), NULL,
A_REGS, Pmode, VOIDmode, 0, 0, opnum,
type);
return 1;
}
+ /* If we see an RTX like (subreg:PSI (reg:SI ...)) we need to reload
+ the subreg. We need to check for PLUS and non-PLUS cases. */
+
+ if (GET_CODE (*x) == SUBREG
+ && GET_MODE (XEXP (*x, 0)) == SImode)
+{
+ if (type == RELOAD_OTHER)
+ type = RELOAD_FOR_OTHER_ADDRESS;
+ push_reload (*x, NULL_RTX, x, NULL,
+ A_REGS, Pmode, VOIDmode, 0, 0, opnum,
+ type);
+ return 1;
+}
+ if (GET_CODE (*x) == PLUS
+ && GET_CODE (XEXP (*x, 0)) == SUBREG
+ && GET_MODE (XEXP (XEXP (*x, 0), 0)) == SImode)
+{
+ if (type == RELOAD_OTHER)
+ type = RELOAD_FOR_OTHER_ADDRESS;
+ push_reload (XEXP (*x, 0), NULL_RTX, &(XEXP (*x, 0)), NULL,
+ A_REGS, Pmode, VOIDmode, 0, 0, opnum,
+ type);
+ return 1;
+}
+
return 0;
}
/* Implements LEGITIMATE_CONSTANT_P. We split large constants anyway,
so we can allow anything. */
int
Re: [m32c] IRA reload failures in libstdc++
Quoting DJ Delorie : I suggest making reload reload the PSImode subreg instead, and make the m32c machine description provide for a tertiary reload so that the value can be loaded & truncated. / Don't know how to set up a tertiary reload (it's not documented anywhere). It's simply a secondary reload of a secondary reload. When a secondary reload is recognized as a reload than cannot be made directly, a tertiary reload is set up. E.g. on the SH, for TARGET_SHCOMPACT, when you load a floating-point register in SImode from memory which is in a high stack slot, you first have a secondary reload in FPUL_REGS, than that reload gets a secondary reload in GENERAL_REGS, then that reload needs an address reload for the sum of the stack/frame pointer and the stack slot offset. From looking at the m32c machine description I got the impression that you can't directly load A_REGS in PSImode from a PSImode subreg of a SImode memory location, but maybe I was mistaken. Is this the type of patch you're thining about? It seems to compile that problem case, but I haven't tried anything else yet. Index: config/m32c/m32c.c === --- config/m32c/m32c.c (revision 146617) +++ config/m32c/m32c.c (working copy) @@ -2040,12 +2040,37 @@ m32c_legitimize_reload_address (rtx * x, It had crossed my mind that you could use LEGITIMIZE_RELOAD_ADDRESS to hide the issue, but that is not the purpose of LEGITIMIZE_RELOAD_ADDRESS; it should be used only to improve efficiency of reloading; if you can get the same reloads with the macros and hooks that drive the generic reload machinery, that is preferred. If there is no way to get a working set of reloads that way, this points to a deficiency in the target-independent reload code. Fixing that deficiency is generally harder initially, but than you should be able to forget about the problem instead of needing to fix it for N targets and have expensive maintenance if the reload internals change. What I was actually talking about was a patch to reload itself to make it reload the SUBREG:PSI instead of the inside of the subreg. It is possible that that would best be done using a new target macro or hook, although you could auto-detect the special circumstances the m32r has here, i.e. no hard register in base BASE_REG_CLASS (you'd really want HARD_REGNO_NREGS outside of fixed_regs) being able to hold an integral mode at least as wide as Pmode. I would consider a patch using LEGITIMIZE_RELOAD_ADDRESS suitable for a release branch where the emphasis is on not breaking anything else (e.g. 4.4.x), or if you are working on a branch/fork that has little prospect of being merged in the mainline in the near future, and want to keep divergence in target-independent files low. If you come to the conclusion that LEGITIMIZE_RELOAD_ADDRESS is actually the best way to handle a class of reload correctness problems, than we probably want a utility function or macro to be used in LEGITIMIZE_RELOAD_ADDRESS that does this safely with less expected knowledge of internal interfaces of reload on the part of the machine description writer, and a change of tm.texi to document when and how to use the new function/macro in LEGITIMIZE_RELOAD_ADDRESS.
Re: [m32c] IRA reload failures in libstdc++
> From looking at the m32c machine description I got the impression > that you can't directly load A_REGS in PSImode from a PSImode subreg > of a SImode memory location, but maybe I was mistaken. The big problem with m32c (--mcpu=m32c) is that pointers are 24 bits, which doesn't correspond to any C integral type. The address in question is illegal because it's trying to use an SImode value as a PSImode pointer. The (subreg ...) in this case is a real operation, not a paradoxical or same-size subreg, so it needs to be extracted from the operation and done as an insn. That insn can be a "no-op" if the right registers are used, but that's the backend's problem. m32c has no problem loading a 24-bit register from a 32-bit memory location. > It had crossed my mind that you could use LEGITIMIZE_RELOAD_ADDRESS > to hide the issue, but that is not the purpose of > LEGITIMIZE_RELOAD_ADDRESS; it should be used only to improve > efficiency of reloading; Then why isn't it called "EFFICIENCIZE_RELOAD_ADDRESS" ? > if you can get the same reloads with the macros and hooks that drive > the generic reload machinery, that is preferred. I put traces on all of them; the subreg is only passed to legitimize. The other ones either get the whole MEM or they get just the REG. > What I was actually talking about was a patch to reload itself to > make it reload the SUBREG:PSI instead of the inside of the subreg. There's code in reload.c around line 5948 (find_reloads_address_1) that tests that case (subregs), but doesn't find anything unusual about it and defers to the generic "reload the contents" case. The comment on else second clause implies it should do what we want, but it doesn't work right - there *are* two registers in A_REGS, but you can't concatenate them, nor would they be a legitimate address if you did. M32C has very complex register classes, it might have uncovered a bug there. FYI, with my legitimize patch (good or bad ;) and -fno-ivopts, m32c-elf-gcc gets these results (which are as good as m32c-elf gets these days): -mcpu=m16c: 48816 98.13% PASS 7 0.01% XPASS 71 0.14% XFAIL 70 0.14% FAIL 770 1.55% UNSUPPORTED 12 0.02% WARNING -mcpu=m32c: 48465 97.43% PASS 7 0.01% XPASS 71 0.14% XFAIL 404 0.81% FAIL 10 0.02% UNRESOLVED 771 1.55% UNSUPPORTED 13 0.03% WARNING
Re: [m32c] IRA reload failures in libstdc++
Quoting DJ Delorie : m32c has no problem loading a 24-bit register from a 32-bit memory location. The only truncsipsi2* alternative part that seems to match is Raa / Sd* . Does that mean that Sd* is as good as m? It had crossed my mind that you could use LEGITIMIZE_RELOAD_ADDRESS to hide the issue, but that is not the purpose of LEGITIMIZE_RELOAD_ADDRESS; it should be used only to improve efficiency of reloading; Then why isn't it called "EFFICIENCIZE_RELOAD_ADDRESS" ? It was called LEGITIMIZE_RELOAD_ADDRESS in analogy to LEGITIMIZE_ADDRESS. Now you could ask why that macro wasn't called EFFICIENCIZE_ADDRESS . I would say that is so because efficiencize is not a word. The idea is that the compiler has generic code to transform a non-legitimate address into a legitimate address, which it will use by default, but if the target wants to override this code, it can do so with the LEGITIMATE_ADDDRESS macro - if there was a specific macro to override the code to efficiencize addresses, that might be called EFFICIENCIZE_ADDRESS. There's code in reload.c around line 5948 (find_reloads_address_1) that tests that case (subregs), but doesn't find anything unusual about it and defers to the generic "reload the contents" case. The comment on else second clause implies it should do what we want, but it doesn't work right - there *are* two registers in A_REGS, but you can't concatenate them, nor would they be a legitimate address if you did. The salient fact here is that there is no register r in A_REGS such that HARD_REGNO_MODE_OK (rn, PSImode) && !fixed_regs[rn] is true for [ r , r + HARD_REGNO_NREGS (r, PSImode) ) . I would think that if that condition can be fulfilled, it will usually be fulfilled by the first register in the class, so I would expect a simple linear search to be generally fast if the condition is fulfilled. If the class is too small, the search should be over soon, too. And if the search fails, you currently get reload errors. On the other hand I have to say that I've often though how stupid it is that reload doesn't generally reload in the smaller mode; if reloading a narrower subreg would be straightforward, reloading the inside of the SUBREG causes a lot of unnecessary code to be generated. The only redeeming point is that this doesn't really happen all that often - stuff like floating-point emulation is so hopelessly inefficient when compiled by gcc that you have to write in assembler anyway if you want speed. Unfortunately, sometimes reloading a wider inside part of a SUBREG is required because of quirks of the hardware or the gcc port - or sometimes because of reload being tied to memory addresses being valid or not depending only on access mode rather on reload register class. So, personally, I would welcome a new macro or hook to make the decision to reload the inside or the outside of the subreg target-dependent.
new offset outside bounds of constant string warning
Hi HJ
According to svn annotate, it was you who authored the new 'offset
outside bounds of constant string warning' warning in GCC (well, I think
so, anyway). The compiler now complains about some code in the C++
demangler:
/home/bje/source/gcc-trunk/libiberty/cplus-dem.c:2651: warning: offset ‘3’
outside bounds of constant string
I tracked this down to the definition of strspn used on my Linux system:
# define strspn(s, accept) \
__extension__ \
({ char __a0, __a1, __a2; \
(__builtin_constant_p (accept) && __string2_1bptr_p (accept) \
? ((__builtin_constant_p (s) && __string2_1bptr_p (s)) \
? __builtin_strspn (s, accept) \
: ((__a0 = ((__const char *) (accept))[0], __a0 == '\0') \
? ((void) (s), 0) \
: ((__a1 = ((__const char *) (accept))[1], __a1 == '\0') \
? __strspn_c1 (s, __a0)\
: ((__a2 = ((__const char *) (accept))[2], __a2 == '\0') \
? __strspn_c2 (s, __a0, __a1) \
: (((__const char *) (accept))[3] == '\0' \
? __strspn_c3 (s, __a0, __a1, __a2) \
: __builtin_strspn (s, accept)) \
: __builtin_strspn (s, accept)); })
Is this something you can fix?
Thanks, Ben
Re: new offset outside bounds of constant string warning
On Thu, Apr 23, 2009 at 03:50:12PM +1000, Ben Elliston wrote: > According to svn annotate, it was you who authored the new 'offset > outside bounds of constant string warning' warning in GCC (well, I think > so, anyway). The compiler now complains about some code in the C++ > demangler: > > /home/bje/source/gcc-trunk/libiberty/cplus-dem.c:2651: warning: offset > ???3??? outside bounds of constant string It was actually Manuel, H.J. just committed the patch. It has been reverted on the 4.4 branch already, and unless something is done on the trunk I'd think it should be reverted on the trunk as well. Jakub
