Re: --enable-plugin option overloaded
Matthias Klose wrote: > --enable-plugin is used by classpath (part of libjava) and now by GCC > itself. disabling the build of the gcjwebplugin now disables plugin > support in GCC as well. Please could the option for enabling GCC plugin > support be renamed to something like --enable-plugins, > --enable-gcc-plugin, --enable-gcc-plugins ? The only reason for not > renaming the existing libjava option is that it was there first, and > that it is part of an imported tree. That doesn't seem like a good enough reason to me. We should rename the libjava option --enable-web-plugin or --enable-browser-plugin . Andrew.
Re: When did arc-elf last build?
On Mon, Oct 19, 2009 at 3:19 AM, Joel Sherrill wrote: > Hi, > > I got a random unsolicited email about arc-elf since > I pop up in google a lot asking cross compiler questions. > I decided to try to build it and as PR41747 indicates > 4.3.4, 4.4.1, and the head all fail building libgcc2.c > in the same way. T > > I did a search for arc-elf in the test results mail > list archives and found none. > > I found a thread (http://gcc.gnu.org/ml/gcc/2003-02/msg01595.html) > where apparently I tried years ago to do the same thing > and didn't have any luck. [Lucky for mail list archives > since I didn't remember this at all. :D ] > > So I am asking.. is arc-elf in use by anyone? When > did it last build? > > And there is no maintainer listed. > > Anybody out there care about it? :) If there is no maintainer listed for this port and it doesn't build I suggest to drop it for GCC 4.5. Richard.
GCC 4.4.2 Released
The GNU Compiler Collection version 4.4.2 has been released. GCC 4.4.2 is a bug-fix release containing fixes for regressions and serious bugs in GCC 4.4.1. This release is available from the FTP servers listed at: http://www.gnu.org/order/ftp.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank individually!
Re: i370 port - constructing compile script
.../configure --target=i370-mvs --prefix=... --with-sysroot=... \ --enable-languages=c where prefix points to the directory where the cross-compiler should be installed, and sysroot points to the directory where the MVS libraries and header are installed. Ok, I used ../configure --target=i370-mvspdp --prefix=/devel/mvscross --with-sysroot=/devel/mvshead --enable-languages=c plus make and make install then I went to mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx and replaced it with a script that does: i370-mvspdp-xxx -S $* For step 3 (cross-building a native compiler), you'd need something along the lines of .../configure --build=i686-linux --host=i370-mvs --target=i370-mvs \ --prefix=... --with-build-sysroot=... --enable-languages=c ./configure --build-i686-linux --host=i370-mvspdp --target=i370-mvspdp --prefix=/devel/mvshost --with-build-sysroot=/devel/mvshead --enable-languages=c I wasn't sure if that --with-build-sysroot was right - pointing to the same headers, but couldn't think of anything else to do with it! This configure run will then use the i370-mvs-gcc cross-compiler you built in step 2 in order to detect MVS host properties. Ok, it (3.4.6 I am using) got as far as: checking size of void *... configure: error: cannot determine a size of void * make: *** [configure-gcc] Error 1 I haven't had a chance to investigate what it's trying to do there, to see if I can devise a workaround. I know that it seems to try to compile with "-g" all the time which gives a warning about it not being supported, but I don't think warnings produce bad return codes like that. BFN. Paul.
char drawstrings[DRAW_MAX][] = { " .. give error
Hi,
I compile an old code which use this and i think its compile with Gcc 2.95
and the
PPC GCC 1998 or 1999
it fail to compile with newer compiler.
#define DRAW_MAX4
char drawstrings[DRAW_MAX][] = {
"Number of points drawn using 3D hardware:",
"Number of lines drawn using 3D hardware:",
"Number of triangles drawn using 3D hardware:",
"Number of quads drawn using 3D hardware:"};
give error on GCC3.4.0
98 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h elements
of array `drawstrings' have incomplete type
gcc4.5.0 report this.
6 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h:98 array
type has incomplete element type
Is this a GGC Bug, or is that syntax no longer support ?.
I change code to this, thats more easy and it compile ok but must check if
its same.
const char * drawstrings[] = {
"Number of points drawn using 3D hardware:",
"Number of lines drawn using 3D hardware:",
"Number of triangles drawn using 3D hardware:",
"Number of quads drawn using 3D hardware:"
};
Bye
Re: i370 port - constructing compile script
Paul Edwards wrote: > Ok, I used > > ../configure --target=i370-mvspdp --prefix=/devel/mvscross > --with-sysroot=/devel/mvshead > --enable-languages=c > > plus make and make install > > then I went to > > mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx > > and replaced it with a script that does: > > i370-mvspdp-xxx -S $* Maybe a more generic way to work around the missing assembler and linker would be to provide dummy scripts i370-mvspdp-as and i370-mvspdp-ld, where the "assembler" would simply copy the assembler source input as text to the "object" file output, and the "linker" would collect all input files into a tar file (or some other archive) as "executable" output ... This would allow usual build processes (including "make") to proceed as expected. > > For step 3 (cross-building a native compiler), you'd need > > something along the lines of > > > > .../configure --build=i686-linux --host=i370-mvs --target=i370-mvs \ > >--prefix=... --with-build-sysroot=... --enable-languages=c > > ./configure --build-i686-linux --host=i370-mvspdp --target=i370-mvspdp > --prefix=/devel/mvshost > --with-build-sysroot=/devel/mvshead --enable-languages=c > > I wasn't sure if that --with-build-sysroot was right - pointing to > the same headers, but couldn't think of anything else to do with it! That should be fine. (The --with-build-sysroot option may actually not be required at all when building just a C compiler.) > Ok, it (3.4.6 I am using) got as far as: > > checking size of void *... configure: error: cannot determine a size of void > * > make: *** [configure-gcc] Error 1 > > I haven't had a chance to investigate what it's trying to do there, to > see if I can devise a workaround. The compiler error output found in the config.log file should hopefully point to the problem ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: __attribute__((optimize)) and fast-math related oddities
tbp writes: > Merrily trying to make a test-case showing how unmanageable it is to > try to override *math* flags per function, i soon had to stop > because... Please file a bug report. __attribute__((optimize())) is definitely only half-baked. Ian
Re: --enable-plugin option overloaded
Andrew Haley writes: > Matthias Klose wrote: >> --enable-plugin is used by classpath (part of libjava) and now by GCC >> itself. disabling the build of the gcjwebplugin now disables plugin >> support in GCC as well. Please could the option for enabling GCC plugin >> support be renamed to something like --enable-plugins, >> --enable-gcc-plugin, --enable-gcc-plugins ? The only reason for not >> renaming the existing libjava option is that it was there first, and >> that it is part of an imported tree. > > That doesn't seem like a good enough reason to me. We should rename > the libjava option --enable-web-plugin or --enable-browser-plugin . We could rename in the top leve configure/Makefile if we don't want to touch the classpath sources. Ian
Re: char drawstrings[DRAW_MAX][] = { " .. give error
Bernd Roesch writes:
> I compile an old code which use this and i think its compile with Gcc 2.95
> and the
> PPC GCC 1998 or 1999
> it fail to compile with newer compiler.
>
> #define DRAW_MAX4
> char drawstrings[DRAW_MAX][] = {
> "Number of points drawn using 3D hardware:",
> "Number of lines drawn using 3D hardware:",
> "Number of triangles drawn using 3D hardware:",
> "Number of quads drawn using 3D hardware:"};
>
> give error on GCC3.4.0
>
> 98 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h elements
> of array `drawstrings' have incomplete type
>
> gcc4.5.0 report this.
>
> 6 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h:98 array
> type has incomplete element type
>
> Is this a GGC Bug, or is that syntax no longer support ?.
>
> I change code to this, thats more easy and it compile ok but must check if
> its same.
>
> const char * drawstrings[] = {
> "Number of points drawn using 3D hardware:",
> "Number of lines drawn using 3D hardware:",
> "Number of triangles drawn using 3D hardware:",
> "Number of quads drawn using 3D hardware:"
> };
This question is not appropriate for the gcc@gcc.gnu.org mailing
list. It would be appropriate for gcc-h...@gcc.gnu.org. Please take
any followups to gcc-help. Thanks.
Your program is not valid C, and I don't see how it could ever have
been compiled by any C compiler. Changing it to something like
char drawstrings[DRAW_MAX][80]
would work.
Ian
Re: --enable-plugin option overloaded
Ian Lance Taylor wrote: > Andrew Haley writes: > >> Matthias Klose wrote: >>> --enable-plugin is used by classpath (part of libjava) and now by GCC >>> itself. disabling the build of the gcjwebplugin now disables plugin >>> support in GCC as well. Please could the option for enabling GCC plugin >>> support be renamed to something like --enable-plugins, >>> --enable-gcc-plugin, --enable-gcc-plugins ? The only reason for not >>> renaming the existing libjava option is that it was there first, and >>> that it is part of an imported tree. >> That doesn't seem like a good enough reason to me. We should rename >> the libjava option --enable-web-plugin or --enable-browser-plugin . > > We could rename in the top leve configure/Makefile if we don't want to > touch the classpath sources. That sounds like a nice solution. Andrew.
Re: __attribute__((optimize)) and fast-math related oddities
On Mon, Oct 19, 2009 at 10:34 AM, Ian Lance Taylor wrote: > tbp writes: > >> Merrily trying to make a test-case showing how unmanageable it is to >> try to override *math* flags per function, i soon had to stop >> because... > > Please file a bug report. > > __attribute__((optimize())) is definitely only half-baked. > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565 -- H.J.
RE: Understanding IRA
Hi Jeff and Vladimir. Jeff: I'd be interested in trying the patch if you can send it my way. Vladimir: Today I have seen reasonable improvements on progressively-trimmed-down versions of a *single* test case by applying some cost adjustments in the case when an operand wants one of our bottom registers and IRA is considering giving it an alternative register or memory. I will be experimenting with different values for these two new costs and some more test cases tomorrow. I wonder if the optimal register allocator will just end up being one that tries all the algorithms and picks the best output for a given case? When it comes to optimisation, I prefer to bend the rules if at all possible! Best regards, Ian -Original Message- From: Jeff Law [mailto:l...@redhat.com] Sent: 16 October 2009 16:45 To: Vladimir Makarov Cc: Ian Bolton; gcc@gcc.gnu.org Subject: Re: Understanding IRA On 10/16/09 08:53, Vladimir Makarov wrote: > > The biggest problem of GCC RA is still reload pass. It frequently > changes decisions of IRA not in a good way. Agreed. Not only may reload make a bad choice, it's horribly unpredictable. Trivial changes often lead to drastically different reloading decisions which in turn drastically change the final output. One of my favorites right now is the round-robin selection of spill registers to encourage reload inheritance. While I certainly understand the reasoning behind the code, it's amazingly frustrating to watch reload choose the worst possible spill register simply because of the round-robin selection. I've got a little hack in the reload-v2 branch which queries IRA to mitigate this problem, but it's merely a short-term hack until I can make reload inheritance go away. jeff
Re: C++ Plugins
On 10/11/09 12:13 PM, Terrence Miller wrote: > (Version 4.5.0) > > There are plugin callbacks which trigger at the end of processing types > and C++ functions, > but I can not find a clean way for plugin code to notice a top-level > variable declaration. > > I'm hoping that the answer does not require the plugin shared library to > bind to global symbols of the compiler (i.e. global_namespace). Why not? That's what dehydra does: it enumerates through the items in global_namespace in PLUGIN_FINISH_UNIT. --BDS
Re: Understanding IRA
Ian Bolton wrote: Hi Jeff and Vladimir. Jeff: I'd be interested in trying the patch if you can send it my way. Vladimir: Today I have seen reasonable improvements on progressively-trimmed-down versions of a *single* test case by applying some cost adjustments in the case when an operand wants one of our bottom registers and IRA is considering giving it an alternative register or memory. I will be experimenting with different values for these two new costs and some more test cases tomorrow. I wonder if the optimal register allocator will just end up being one that tries all the algorithms and picks the best output for a given case? When it comes to optimisation, I prefer to bend the rules if at all possible! I did not try progressive register allocator (in which I have some doubts) but I did a lot of experiments recently (last year) with ILP based register allocators: from simple spill model (which pseudos should be spilled) to RA with coalescing, live range splitting, rematerialization, and code selection (it needs models on hard reg levels) including some models closed to Apel's and two Wilken's approaches. The simplest model can be only used to solve medium-size functions in reasonable time (about 10 minutes). But even this model can not be used for function like reload.c::find_reloads. More complex model problems can not be solved even for many tiny benchmarks (like heapsort) in reasonable time. Although I used GLPK which is much slower than the best package (CPLEX). Other algorithms for soliving ILP (like Balas' one) are even much worse. The improvement for the simplest model was not significant unless profiling was used (in this case some SPECInt2000 benchmarks were improved upto 20% on x86). In any case, I did not find optimal RA based on ILP is practical. About 4 years ago, I tried QAP (quadratic assignment problem) model approaches with the same conclusion. Although I did not try multi commodity flow network approach for which there are better specialized algorithms because there are no good GPL-based packages for this (unfortunately the best one MCF has no such license). It could be an interesting research.
Re: C++ Plugins
Benjamin Smedberg wrote: On 10/11/09 12:13 PM, Terrence Miller wrote: (Version 4.5.0) There are plugin callbacks which trigger at the end of processing types and C++ functions, but I can not find a clean way for plugin code to notice a top-level variable declaration. I'm hoping that the answer does not require the plugin shared library to bind to global symbols of the compiler (i.e. global_namespace). Why not? That's what dehydra does: it enumerates through the items in global_namespace in PLUGIN_FINISH_UNIT. --BDS Because it makes the name "global_namespace" and the list order(TREE_CHAIN (t) points to a declaration located earlier in the file than t) be part of the plugin interface and these two items are not documented. Also you end up with one way of handling top-level types (PLUGIN_FINISH_TYPE) and functions (PLUGIN_CXX_CP_PRE_GENERICIZE) and a different way of handling variables. A better scheme (IMO) would be to have a plugin triggered when the declaration of a variable is complete and another pair of plugins for scope entry/exit. Terrence
Improving code with no offset addressing
Hi there. The architecture I'm working on porting gcc to has indirect
addressing but no constant offset or register offset versions. Code
like this:
void fill(int* p)
{
p[0] = 0;
p[1] = 0;
p[2] = 0;
p[3] = 0;
Turns into:
X = p
*X = 0
X = X + 4
*X = 0
X = p
X = X + 8
*X = 0
X = p
X = X + 12
*X = 0
at both -O and -O2. Note that the first step recognises that X
contains p and correctly increases it instead of rebuilding it.
I'd like to generate the following code instead:
X = p
*X = 0
X = X + 4
*X = 0
X = X + 4
*X = 0
X = p
X = X + 4
*X = 0
What is the best way to approach this? It seems to be common across
ports (see the note on ia64 and ARM Thumb below). Is there a cost
function I can change? Will changing LEGITIMIZE_ADDRESS fix it? Is
there some type of value tracking that could be turned on/added?
I've checked the ia64, which also only has indirect addressing, and
ARM Thumb which has limited offsets. ia64 generates the same reload
base/add offset as mine:
mov r14 = r32
;;
st4 [r14] = r0, 4
;;
st4 [r14] = r0
adds r14 = 8, r32
;;
st4 [r14] = r0
adds r14 = 12, r32
;;
st4 [r14] = r0
adds r14 = 16, r32
ARM Thumb does the same when the offset is large (p[70] and p[71] in this case):
str r3, [r0] ; p[0]
str r3, [r0, #4] ; p[1]
str r3, [r0, #8] ; p[2]
str r3, [r0, #12] ; p[3]
mov r2, #140
mov r3, #0
lsl r2, r2, #1
str r3, [r0, r2] ; p[70]
mov r2, #142
lsl r2, r2, #1
str r3, [r0, r2] ; p[71]
Thanks for any pointers,
-- Michael
Re: When did arc-elf last build?
Joern Rennecke wrote: Quoting Joel Sherrill : Hi, I got a random unsolicited email about arc-elf since I pop up in google a lot asking cross compiler questions. I decided to try to build it and as PR41747 indicates 4.3.4, 4.4.1, and the head all fail building libgcc2.c in the same way. T I did a search for arc-elf in the test results mail list archives and found none. The arc-elf port in mainline gcc is for the architecture used by the ARCtangent-A4 and older cores, which has been superseded by the ARCompact architecture. The first article that a Google search turned up suggests that this was in 2001: http://www.design-reuse.com/news/632/arc-16-32-bit-instruction-architecture-memory-requirements-up-30-per-cent.html See also PR target/39303 . I went back to gcc 4.2.4, 4.1.2, and 3.4.6. This target failed at exactly the same point. So it works on a branch but there is no maintainer. Merging the working code onto the truck would be better than letting it bitrot, wouldn't it? The code on the trunk is unbuildable and has been for a long time. I'm not an arc user but wonder if it is better to have functional code on the trunk without a maintainer since it is available than non-functional code on the trunk without a maintainer. :) If merged, I will at least volunteer to build it once and run the tests if a free simulator is available. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: When did arc-elf last build?
Quoting Joel Sherrill : The code on the trunk is unbuildable and has been for a long time. I'm not an arc user but wonder if it is better to have functional code on the trunk without a maintainer since it is available than non-functional code on the trunk without a maintainer. :) It depends on some patches outside the arc directory. Some submitted as separate patches, some not, but none of them reviewed. Some documentation is incomplete or not written yet (.texi patches tend to cost more effort merging long-term than to write). You'd also need another version of binutils for ARCompact support - this is available as binutils-arc-20081103-branch on sourceware, but not fully up to GNU coding standards. If merged, I will at least volunteer to build it once and run the tests if a free simulator is available. Yes, a Free simulator is available on sourceware with the tag arc-sim-20090309 .
Re: Alias analysis or DSE problem?
Thanks a lot for the help! It looks like creating a temporary
took care of it.
On Sat, Oct 17, 2009 at 7:41 AM, Richard Guenther
wrote:
> I think the call you insert is not of valid gimple form - an address
> argument has to fulfill the is_gimple_min_invariant() predicate.
> Thus I suspect you have something like &ptr->field in there which
> needs a temporary.
That was it. Actually, the TREE was of the form
ADDR_EXPR(ARRAY_REF(STRING_CST)), which does not satisfy
is_gimple_min_invariant().
The strange thing is, I copied that structure verbatim from
unmodified GCC. I'm trying to insert a call that looks like:
foo("some string constant");
If I put that function call in a simple C program and dump out
the resulting GIMPLE, it gives me the ADDR_EXPR that was causing
problems in refs_may_alias_p_1().
Does anyone know why that structure is ok in the contexts that
GCC is using it but not in the context that my plug-in uses it
in?
--Justin
Re: __attribute__((optimize)) and fast-math related oddities
On Mon, Oct 19, 2009 at 7:34 PM, Ian Lance Taylor wrote: > Please file a bug report. > __attribute__((optimize())) is definitely only half-baked. Apparently the code i've posted is just a variation around that 1 year old PR 37565 and if that doesn't work, worrying about the rest is entirely futile. Half baked you say? It's comforting to see that much optimism but couldn't the doc be adjusted a bit to reflect the fact that the baker got hit by a bus or something? PS: i'm sorry that i've missed that PR in my search, but i presumed the issue was much more specific.
[MIPS] cannot split restore_gp
Hi,
G++ could not split restore_gp.
Please check this test (from #line 15017 "configure" of
gcc/libstdc++-v3/).
# cat foo.cpp
struct S { ~S(); };
void bar();
void foo()
{
S s;
bar();
}
# ~/dev/gcc45/build/gcc/cc1plus -quiet foo.cpp -o foo.s -mno-shared -mplt
-mabicalls -G0
foo.cpp: In function â?~foo()â?T:
foo.cpp:7:1: error: could not split insn
(insn 29 28 30 (parallel [
(set (reg:SI 28 $28)
(unspec_volatile:SI [
(const_int 0 [0x0])
] 7))
(clobber (reg:SI 2 $2))
]) 555 {restore_gp} (nil))
foo.cpp:7:1: internal compiler error: in final_scan_insn, at final.c:2651
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Something may be wrong before we reach the "final" pass.
(Or, we should have split restore_gp earlier.)
Any idea? Thanks!
Regards,
Chao-ying
Need help in understanding code generated for C++ exception handling
Hi, I have compiled and generated a C++ shared library with the "-fPIC" option. But this shared library requires text relocation during runtime and is not usable on seLinux which disables writeable text segments. The text relocation is due to use of exceptions inside the shared library. There is a segment ".gcc_except_table" created in the shared library and it contains symbols suffixed with "$$LSDA" :- 0013df38 <_ZN6comref4runt11userdef20releasebackEPS1_$$LSDA>: 13df38: ff 00 incl (%eax) 13df3a: 18 01 sbb%al,(%ecx) 13df3c: 0c 1c or $0x1c,%al 13df3e: 03 2f add(%edi),%ebp 13df40: 01 52 0aadd%edx,0xa(%edx) 13df43: 6d insl (%dx),%es:(%edi) 13df44: 00 66 1aadd%ah,0x1a(%esi) 13df47: 00 00 add%al,(%eax) 13df49: 02 00 add(%eax),%al ... 13df4b: R_386_32_ZTIN6comref4runt12genExceptionE Can someone please help in understand the issue and how to work around? Thanks, Shankar Yahoo! India has a new look. Take a sneak peek http://in.yahoo.com/trynew
