Re: __LDBL_MAX__ exceeds range of 'long double'
Jonathan Wakely wrote: Sorry for the late reply. It does indeed fix the problem I saw with 4.0 on FreeBSD, but I'm now seeing this with 3.4.4 20050228 too, so I think it's a regression introduced in the last 6 weeks or so. Is the same fix safe to apply to 3.4? Yes, it should also be safe for gcc-3.4. This problem was exposed in gcc-3.4 by this patch, which is presumably the same patch that exposed this on mainline. 2004-11-12 Richard Henderson <[EMAIL PROTECTED]> PR 17778 * config/i386/i386.h (TARGET_96_ROUND_53_LONG_DOUBLE): New. * config/i386/freebsd.h (SUBTARGET_OVERRIDE_OPTIONS): Remove. (TARGET_96_ROUND_53_LONG_DOUBLE): New. * config/i386/i386-modes.def (XF): Use it. My patch is needed to make this work with -E or --save-temps. Since this is a clear regression, and a relatively safe patch, I will test the patch with gcc-3.4 and then check it in if there is no problem. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Building GCC on Native Platform
On Fri, 2005-03-04 at 21:32, Vivek Takalkar wrote: > Could some one help me in building GCC as NATIVE GCC on platform other > than INTEL PC, say ARM, SPARC, etc. The procedure for building a native gcc is generally the same regardless of target. If you know how to build it on one machine, then you can build it on any machine. See the install instructions, either in the sources our on the web site that give more info. There are some targets that have special requirements. These are documented in the same place, in the install docs. I didn't see the original message on the gcc list. If you had a problem with the spam filter, I'd suggest using fewer (preferably none) capital letters in the subject line. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: IA64 record alignment rules, and modes?
Gary Funck wrote: Question: If we assume that a TImode would've been a more efficient mode to represent the record type above, would it not have been acceptable for the compiler to promote the alignment of this type to 128, given there are no apparent restrictions otherwise, or are there other C conventions at work that dictate otherwise? Is there a configuration tweak that would've led to using TImode rather than BLKmode? The ABI says that the type has alignment of 64-bits, because that is the largest alignment among the types used in the structure. It is not OK to promote the alignment of the type to 128-bits, because we might be given a pointer to an object created by a different compiler which has only the 64-bit alignment required by the ABI. If we assume a larger alignment, then we might generate code that fails (or rather in this case triggers an unwanted kernel unaligned access fixup). Also, this might break the ABI, since structures with different alignments may be passed differently as arguments. Also, as others mentioned, this breaks structure layout when this structure is nested inside other structures. There may also be other problems. It would be OK to promote the alignment of a variable with this type to 128-bits. We could then perhaps generate more efficient code to access this variable, and if we take a pointer and pass it to another compiler, there won't be any problems. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 3.4.3 static constants, named sections, and -fkeep-static-consts
Gary Funck wrote: When compiled with GCC 3.4.3, at -O2, the ident string above will _not_ appear in the executable. This is apparently expected behavior. See the docs for __attribute__ ((used)). Contrary to the docs, it works for more than functions. However, interestingly, gcc -fkeep-static-consts -O2 t.c did not retain the ident string, rcsid, defined above. Shouldn't -fkepp-static-consts have ensured that this static constant would appear in the executable? Try re-reading the docs. -fkeep-static-consts is the default. The purpose of this is that we don't perform this optimization at -O0 normally, but if you use -fno-keep-static-consts, then we do. So this option can let you remove static consts in extra cases, but will never prevent the compiler from removing them. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Bad link on webpage
Giovanni Bajo wrote: I would like to still get hold of the information that used to be present at that page because they were in fact very useful. This is what web search engines are for. Going to yahoo, typing gcc visibility, and then clicking on the "cached" link for the first search result, I get a copy of the page. http://216.109.117.135/search/cache?p=gcc+visibility&sm=Yahoo%21+Search&toggle=1&ei=UTF-8&u=www.nedprod.com/programs/gccvisibility.html&w=gcc+visibility&d=C31F2BCCE8&icp=1&.intl=us -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Question about "#pragma pack(n)" and "-fpack-struct"
feng qiu wrote: > When I compile with "gcc" ,the output is 6.But the output is 5 when > using "-fpack-struct" to build,and the "#pragma pack(2)" seems to be > invalid.What is the reason? -fpack-struct and #pragma pack(2) are contraditctory instructions, and -fpack-struct wins. It was never the intent to allow both. Current gcc sources will give a warning saying that the pragma pack is being ignored. If you want some structures that aren't fully packed, then you can't use -fpack-struct. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 3.4.x => 4.0 compatiblity
Andrew Muraco wrote: After the compiler is installed im going to recompile glibc using gcc 4.0 and recompile other major parts of the system This is probably more trouble than it is worth. gcc-4 won't be fully ABI compatible with gcc-3.4, and you are likely to find bugs in gcc and various other packages, as gcc-4 hasn't been used to build a full distro yet. How much trouble you see will depend on your target, which you didn't specify. Unless you are in the business of making distros, or want to learn how to build a distro, it is best to stick with the compiler that your existing distro supports. Also, it is probably a little early to worry about this, as the gcc-4 release is probably still 2 months away. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: How is lang.opt processed?
Steve Kargl wrote:
I'm looking to the broken behavior of gfortran with its
-r8, -i8, and -d8 options. gfortran/lang.opt contains
You can't choose any name for front-end options. There are complicated
rules for determining whether an option is for the gcc driver or
preprocessor or front-end or back-end or assembler or linker or collect
or something else. If you deviate from these rules, you are asking for
trouble.
Front-end options should always start with -f.
I would guess the problem is with the specs. An option won't work
unless the gcc driver knows that the option should be passed to g95.
The -d8 option "works" because it conflicts with the -d* debugging
options which are already being passed to g95. Note however that all
-d* options are reserved for debugging dumps, and if some time in the
future we decide to add a -d8 debugging dump, then the fortran front end
option name will have to change. It should have never been called -d8
in the first place. See the "%{d*}" in cc1_options.
The -i8 and -r8 options meanwhile do not work because there is no spec
to handle them. You would have to add %{i8} and %{r8} to
fortran/lang-specs.h. However, if you do this, then you are creating a
liability for yourself. The problem is that there may exist some target
that requires passing i8 or r8 to the preprocessor or linker or some
other subprogram, and in that case, you have an unresolvable conflict.
It is unlikely that such a target exists, but there is no way to prove
that there are none or never will be one. If such a conflict does
arise, it will be arguable who is wrong, and we will have a mess. Note
that -i* is normally reserved for preprocessor options, and -r is a
linker option.
Meanwhile, we know that -f is safe, because all -f* options are reserved
for the compiler front-end. If we find a target that requires a -fr8
linker option, then that target linker is by definition broken, and it
isn't your problem.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Target specific memory attributes from RTL
Balaji S wrote: But, i'm not able to access target specific attribute from second level of indirection onwards. For example, int **gpi ; Note that in this case finding the target means indirecting through a memory address, and hence we would have to track the attributes of all memory locations which is a difficult and perhaps unsolvable problem. As I said before, I think what you are trying to do is fundamentally flawed. If you need attributes, you use them when generating RTL, not when optimizing or emitting RTL. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Target specific memory attributes from RTL
Paul Schlie wrote: Does anyone have any further insight with respect to this potential problem? I don't believe there is any problem here if attributes are used correctly. If you need attributes to work differently than they already do, then you will have to extend gcc yourself. I also think this is off topic, as you seem to be talking about something different than the original poster. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Spill cost
Rajkishore Barik wrote: Does anyone know how to obtain the overall spill cost for the old reg alloc of GCC (global.c)? We don't have existing hooks for this, but it shouldn't be hard for you to add them yourself. Try looking at the code, see in particular dump_global_regs in global.c and the uses of dump_file in reload1.c. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: gcc-3.4.4-20050211: maybe a danger behaviour
Denis Zaitsev wrote:
a) Formally, the code is correct. As p->what can never be < 0
according to its type.
I am assuming this is C code. C and C++ have different rules for enums.
This isn't strictly true. The C standard does not say that enums are
unsigned. It only says that they are equivalent to an integral type
with a few restrictions, and an implementation can choose to make it
signed or unsigned when all enum values are non-negative. So depending
on the compiler, it could be possible for p->what to be negative.
b) GCC _silently_ allows the {-1} initialization for that type, even
with -Wall.
This is because there is no such thing as an enum type in C, enums are
just an alias for an integral type, and it is never wrong to store -1 in
an integral type, even if it is unsigned. (C++ on the other hand will
complain here because C++ has actual enum types distinct from integral
types.)
Uncommenting the c= -1 member of enum, or explicit casting p->what to
int solves the problem, of course. But maybe some warning would be
appropriate in such a situation?
You will get a warning if you compile with -W.
tmp.c:22: warning: comparison of unsigned expression >= 0 is always true
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Help : Instruction Scheduling
Sachin Sonawane wrote: But I want to see the Assembly code with no-ops. How do I go for it? Which construct in .md file or any other file do I need to set for it? We have no support for emitting padding nops. You would have to modify the x86 backend to emit them, and this would be a non-trivial change. Try looking at the documentation for scheduler hooks, and try to figure out how to emit a padding nop if we need to increment the cycle count without scheduling any instructions. An alternative would be to look at the scheduler dumps. Try compiling with -O2 -da -fsched-verbose=2 and look at the .sched2 dump. It will list every instruction scheduled and an estimate of which cycle the compiler expects it to execute in. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: what's the proper way to configure/enable/disable C exception handling?
Paul Schlie wrote: - might forcing sjlj exceptions help? With what consequences? Perhaps, try it and see. Less efficient C++ EH support. We also have C extensions for EH support, but they are not widely used. - or might it be best for me to attempt to refine the baseline exception data structure definitions to be more target type size support aware? The data structures are defined by the Itanium Unwind ABI, which has subsequently been included in the C++ ABI standard. The Itanium Unwind ABI requires 64-bit values, and hence the C++ ABI by extension also requires 64-bit values here. Since changing the sizes violates the C++ ABI, it isn't something we can do by default. It could perhaps be done for specific targets which don't have 64-bit integral types, but there would have to be a good justification for it, and the patches would have to be minimally invasive. It isn't clear if it is worth the trouble. We have had type problems with this code before, and people are going to be unwilling to mess with it. You haven't stated precisely what the problem is here, i.e. what exact error you get, so it isn't clear what else to recommend. Maybe you can solve the problem by dropping support for C++ and not building parts of the C++ EH infrastructure. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Specifying a linker script from the specs file
Shaun Jackman wrote: Why does the above specs snippet cause gcc to forget it's linking against thumb libraries? The -mthumb support works by passing extra -L options to the linker. Try using -v and looking at the linker options. You didn't include your linker script, but a possibility here is that you are overriding path names in your linker script, preventing the -L options from working as intended. Also, note that there is a linker --verbose switch that may help debug what the linker is doing. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: mthumb in specs file
Shaun Jackman wrote: Is it possible by hacking the specs file to change the target for arm-elf-gcc from -marm to -mthumb? I tried a few obvious things like changing marm in *multilib_defaults to mthumb, but this did not have the desired effect. You have to do more than that. multilib_defaults only controls what libraries we link against. You also need to pass -mthumb by default to cc1 and perhaps also the assembler and linker. Try using gcc -v -mthumb and comparing the result against gcc -v, and then writing specs that mimic what -v -mthumb does. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Feature request: Globalize symbol
Fredrik Hugosson wrote:
My proposal is the following new options:
-fglobalize-symbol=SYMBOLNAME
-fglobalize-symbols=FILENAME
-fglobalize-all-symbols
It is unlikely someone will volunteer to implement a feature that only
you need.
Globalizing a symbol in a shared library is potentially unsafe, and that
may resulting in linker conflicts, or it may result in a shared library
variable being overriden by a variable in another module causing silent
changes in behaviour.
Another way to attack this problem would be to add accessor functions to
the shared libraries. Presumably you only need to be able to read/write
the variables, so an accessor function would solve this problem without
compiler changes. So if you have a variable
static int slib_var;
Add functions
int __unittest_read_slib_var (void) { return slib_var;}
void __unittest_set_slib_var (int value) { slib_var = value; }
to the shared library when you compile it.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 3.4.x => 4.0 compatiblity
On Thu, 2005-03-10 at 15:27, Joe Buck wrote: > On Thu, Mar 10, 2005 at 12:39:28PM -0800, James E Wilson wrote: > > Also, it is probably a little early to worry about this, as the gcc-4 > > release is probably still 2 months away. > While I usually hesitate to disagree with Jim, I will in this case. I > *hope* that clueful people will worry about this, so that we can fix as > many bugs as possible (or at least come up with some workarounds or > warnings) before we ship 4.0. The original message was talking about updating to gcc-4 after the official release. This bit got cut out when I trimmed down the excerpts. The point of my message is that since the official release hasn't occurred yet, and isn't likely to occur for another couple of months, it is too early to speculate about how well gcc-4 will work for end users after the release. There could be significant changes between now and then. I certainly didn't intend to discourage clueful people from trying to build a distro with it in the meantime. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Feature request: Globalize symbol
On Thu, 2005-03-10 at 16:55, Hans-Peter Nilsson wrote: > But that requires source-level instrumentation. Isn't a compiler option -fglobalize-symbol also a form of source-level instrumentation? Either way, you need the source, and you get different code emitted. If you are interested in implementing this, you should consider how this will interact with other compiler features such as __asm__, attribute ((alias)), and C++/Java name mangling. Also, I think the IPA support will rename variables behind your back to try to avoid conflicts, e.g. if you try to compile two source files into one object file. There are a number of possible complications here for the -fglobal-symbol=SYMBOLNAME option which should be carefully considered when the option is implemented. The meaning of the other two options seems clear enough. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: gnattools folder and GCC snapshots
Ranjit Mathew wrote: IMHO "gnattools" should be added to "ADA_DIRS" in "gcc_release" to generate snapshots properly. Otherwise, people who do not download and install "gcc-ada" tarballs will get a bootstrap error. I verified that if I download the gcc-core snapshot and try a bootstrap, I get a failure building gnattools. This failure goes away if gnattools is moved from gcc-core to gcc-ada. I tested your patch by hand crafting a release source tree, and then running "gcc_release -r 4.1 tarfiles". All this does is build the tarfiles. It doesn't touch the cvs repository or the ftp site. I did this with and without your patch, and verified that the only change was that gnattools moved from the gcc-core file to the gcc-ada file. I believe this testing is sufficient. I checked in the patch. I have attached the patch I checked in, so it would get archived in the gcc-patches list. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com 2005-03-10 Ranjit Mathew <[EMAIL PROTECTED]> * gcc_release (ADA_DIRS): Add "gnattools". Index: gcc_release === RCS file: /cvs/gcc/gcc/maintainer-scripts/gcc_release,v retrieving revision 1.63 diff -p -p -r1.63 gcc_release *** gcc_release 14 Aug 2004 16:47:52 - 1.63 --- gcc_release 11 Mar 2005 01:41:34 - *** SOURCE_DIRECTORY="" *** 582,588 # The directories that should be part of the various language-specific # tar files. These are all relative to the top of the source tree. ! ADA_DIRS="gcc/ada libada" CPLUSPLUS_DIRS="gcc/cp libstdc++-v3" FORTRAN_DIRS="gcc/f libf2c" FORTRAN95_DIRS="gcc/fortran libgfortran" --- 582,588 # The directories that should be part of the various language-specific # tar files. These are all relative to the top of the source tree. ! ADA_DIRS="gcc/ada libada gnattools" CPLUSPLUS_DIRS="gcc/cp libstdc++-v3" FORTRAN_DIRS="gcc/f libf2c" FORTRAN95_DIRS="gcc/fortran libgfortran"
Re: Feature request: Globalize symbol
On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote: > This isn't a source-level modification, by definition. And I could argue that my suggestion isn't a source-level modification either, or I could argue that your suggestion really is a source-level modification, but it seems pointless to argue about this. Certainly, a gcc option is more convenient, if someone is willing to volunteer to implement it. > Of course! The simple (and best) way out is to define what > happens in all those situations as the equivalent of removing > "static" for such an identifier in file scope I think you missed my point. The proposed -fglobalize-symbol=SYMNAME option assumes that it is obvious what a variable's symbol name is. Variables often have different names in the input source file and the output object file. Also, variables can sometimes have multiple names in the input source file. This may depend on gcc extensions being used. Or in a language like C++, it may depend on the context that the variable is declared in, e.g. namespaces, class contexts, template expansion, etc. So when an option mentions a symbol name, exactly how do we find the variable that matches that symbol name? But it looks like we have solved this problem before, because we have pragmas that take symbol names. See the comments in c-pragma.c for #pragma redefine_extname. The next question then is whether the proposed option is still useful if we have to apply all of the same restrictions that #pragma redefine_extname requires. Also, there is still the question of how this gets used for instrumentation. For instance, you mentioned that you want to use linker wrapping, but the linker wrapping would have to use the assembler name of the symbol which can be arbitrarily different from the source level variable name. So you need two possibly very different symbol names for the -fglobalize-symbol and --wrap options, and there is no foolproof way for the external unit tester to know the mapping between the -fglobalize-symbol DECL_NAME and the --wrap options DECL_ASSEMBLER_NAME. Of course, this won't be a problem in the common case for ordinary C global variables, but it does mean that the unit tester won't be able to handle all cases. Hence this may not be the best approach to solve the general problem of unit testing. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Feature request: Globalize symbol
On Thu, 2005-03-10 at 20:14, Hans-Peter Nilsson wrote: > That question isn't applicable or maybe I should say "by > identity mapping". To wit, SYMNAME refers to whatever has > "static" in front of it *in the source code*, but for which you > want it removed, i.e. globalized (speaking in C terms). I think you fail to appreciate the complexity of a compiler symbol table. Particularly when GNU extensions are involved, and when languages like C++ are involved. If you restrict yourself to ISO C, then yes it will probably work in all cases. Otherwise, no, it won't. You really should look at the #pragma redefine_extname and extern_prefix documentation, which lists a number of cases where this "by identify mapping" concept doesn't work. > I mentioned --wrap just as *one* way of modifying SYMNAME later > on (so please don't get stuck on it): OK. I'll concede this isn't a reason to reject the patch, it was just something to consider in the design. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: How is lang.opt processed?
Toon Moene wrote:
Ditto. Jim, are you reading from some documentation about this option
processing that I couldn't find ? I've spend hours and hours to try to
deduce the option processing rules from debugging various parts of the
gcc driver, with no success.
I doubt that this stuff is well documented. There are some comments at
the top of gcc.c that give basic info on option processing, and there
are comments a bit farther down that explain how spec strings work.
Actual argument handling happens inside do_spec* as a side-effect of
reading the spec strings. If an option matches a spec string, it is
processed. If it doesn't, it is ignored. This happens in
handle_braces, where it calls process_marked_switches. There is also
some earlier argument parsing, which does stuff like handle arguments
with options, see translate_options. There is also some code to check
for options that aren't handled by any spec string, see
validate_all_switches.
The rules for which options go to which programs were developed by trial
and error, and most of the errors happened long ago. These rules are
now encoded in the various spec strings. So cc1_options has %{d*},
%{f*}, and %{m*} which implies that -d*, -f*, and -m* are all reserved
for compiler binaries. cpp_unique_options contains %{i*} which implies
that all -i* options are reserved for the preprocessor.
LINK_COMMAND_SPEC contains %{e*}, %{u*}, %{L*}, and %{T*} which implies
that -e*, -u*, -L*, and -T* are all reserved for the linker. Etc.
If you want to use an option that differs from the normal naming scheme,
then you need to examine all spec strings in the gcc driver and all
target files to make sure that there is no conflict. And this isn't
foolproof, because there could be conflicts with systems not supported
yet, or options on existing targets that aren't explicitly handled by
specs. It is easier and safer to just stick to the normal naming
scheme, -d* for debugging dumps, -f* for front end and optimizer
options, -m* for target dependent options, etc.
If you do need to extend the system, then it is best to use option names
similar to existing ones. For instance, -z and -Z are assumed to be
linker options, so if you need a new linker option then something like
-zthis or -Zthat might be a good choice. This trick is used by darwin
which supports a slew of -Z* options that look mostly like special
linker options. This trick doesn't work as well with a language front
end though. Darwin doesn't have to worry about conflicting with other
targets. You do. So it is best if a language front end is conservative
about option choices.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Write after approval - processed by "None".
Toon Moene wrote: Again I got a reaction of accepting write after approval (this time for Feng Wang) as "processed by: None". System adminstration work is performed by [EMAIL PROTECTED] You should ask them. Checking the overseers mailing list archive, I see that the last message is an automated message about the Feng Wang service request, though the links appear to be broken, or maybe I don't have the proper priviledges to see them. If service requests aren't getting handled, then we might need someone to volunteer to help with overseers work. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Write after approval - processed by "None".
On Fri, 2005-03-11 at 16:01, Joe Buck wrote: > [EMAIL PROTECTED] works just as well, since it's the same machine by > a different name. On this list we should be advertising the gcc.gnu.org > name, I think. True. But if you want to look at the mailing list archive, you have to use the non GNU name for the machine, as they are two different web sites. This is why I usually prefer the non-GNU name when referring to the overseers list. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Feature request: Globalize symbol
On Fri, 2005-03-11 at 08:12, Hans-Peter Nilsson wrote:
> I don't really understand what you mean: if a thing is called
> "foo" in the source, then -fglobalize-symbol=foo would work.
My main concern is that we have a long history of adding flawed features
that have to be later removed. So I want you to try to think about
anything that might possibly go wrong now instead of just assuming that
it will obviously work. You are proposing a new kind of option, one
that first translates symbolnames to variable names, and then changes
their linkage, so you need to carefully define exactly how this works in
all cases, and how it interacts with all existing gcc features.
I thought looking at the existing pragmas was a good start, as they
already have support for mapping a symbolname to a variable. You are
right that these work on external names not statics, and hence aren't
completely relevant. That is a mistake on my part. They do mention the
C++ extern "C" {} limitation which does apply here. There may or may
not be anything else useful there.
The original poster mentioned an interaction with .hidden, so you need
to define how the feature of removing static interacts with visibility
attributes.
There may also be other issues that need to be dealt with. It would be
useful to browse the C standard and the list of gcc extensions to look
for possible issues that might need to be dealt with. It may also be
useful to look at how gcc internals handle static and look for potential
problems.
I am not opposed to the feature in principle. I just think that you
aren't being vigorous enough in defining it. I'd like to see a formal
specification of what the option does, both in how the symbolname to
variable mapping works, and in how the static removal works. A
carefully written implementation and carefully written documentation
would probably be sufficient, as we generally don't do formal
specifications here. Again, I think the pragmas are a useful reference
here, as you can see the amount of care that was taken to try to define
the meaning of every possible interaction with other gcc features both
in the documentation, and in the source.
Richard however does appear to be objecting in principle, which is
another matter.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Write after approval - processed by "None".
On Fri, 2005-03-11 at 17:48, Ian Lance Taylor wrote: > All true, but I want to note that the preferred non-GNU name is > sourceware.org. What about the trademark status? Last I heard, the trademark holder had asked us to stop using the name. That is when and why the machine got renamed away from sourceware.org. I have been careful not to use the sourceware name since. The sourceware.org name was kept for convenience, but wasn't supposed to be advertised. Did this trademark issue ever get resolved? Checking the US Patent and Trademarks office, I see that there is still a computer software trademark for sourceware, owned by Pliant Technologies, which was registered in August 1997. Pliant Technologies got bought by Market Central in 2003, and Market Central is still using this trademark. http://www.marketcentral.com/ -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: are link errors caused by mixing of versions?
Michael Cieslinski wrote: /usr/bin/ld: Warning: size of symbol `ACE_At_Thread_Exit::~ACE_At_Thread_Exit()' changed from 46 in .shobj/POSIX_Proactor.o to 48 in .shobj/Proactor.o This looks like a destructor function name, which means two different versions of gcc generated different code for the same function, which is a common occurrence, and not anything to worry about. `typeinfo name for ACE_Sbrk_Memory_Pool' referenced in section `.gnu.linkonce.d._ZTI20ACE_Sbrk_Memory_Pool[typeinfo for ACE_Sbrk_Memory_Pool]' of .shobj/Local_Name_Space.o: defined in discarded section `.gnu.linkonce.r._ZTS20ACE_Sbrk_Memory_Pool[typeinfo name for ACE_Sbrk_Memory_Pool]' of .shobj/Priority_Reactor.o This means we have a link-once data section that has a reference to a link-once read-only data section, and the read-only data section was deleted by the linker as unused. This is not good, but it isn't clear if the mixing of compiler versions had anything to do with this. It is possible that some ABI change got implemented after the code-freeze was lifted, thus causing the incompatibility. Or this could be a bug in the application. Or this could be a lot of other things. We would need more info. `vtable for ACE_Sig_Adapter' referenced in section `.gnu.linkonce.t._ZN15ACE_Sig_AdapterD0Ev[ACE_Sig_Adapter::~ACE_Sig_Adapter()]' of .shobj/Local_Name_Space.o: defined in discarded section `.gnu.linkonce.d._ZTV15ACE_Sig_Adapter[vtable for ACE_Sig_Adapter]' of .shobj/POSIX_Proactor.o This is a similar case, except that we have a link-once text section referencing a symbol in a link-once data section, and the data section was deleted as unused. /usr/bin/ld: BFD 2.15.91.0.2 20040727 internal error, aborting at ../../bfd/elf64-x86-64.c line 1873 in elf64_x86_64_relocate_section This is a binutils bug. The linker shouldn't die like this, even if the compiler created bogus output. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Target specific memory attributes from RTL
Balaji S wrote: _On 11-Mar-2005 02:48, James E Wilson san wrote_: Is expression evaluation (expr.c, expand_expr_real) converting tree into RTL, the right place to extend GCC as required? Basically, yes. However, variables declarations are typically handled separately from the expression, so if you want to retain info about variables, you need to do it elsewhere, when the variable's DECL_RTL is generated. Globals are handled differently than locals, but probably only globals matter, in which case you should see make_decl_rtl and encode_section_info. Also, note, in current sources, this stuff is all different, because the tree to RTL expander has been replaced with tree to gimple to RTL expander. So what you are doing is probably of no long term use. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Merging calls to `abort'
Richard Stallman wrote: Currently, I believe, GCC combines various calls to abort in a single function, because it knows that none of them returns. To give this request a little context, consider the attached example. If I compile this with -O2 -g, and run it under the debugger, it tells me that the program died at line 7 (j == 0) which is impossible. It is easy to tell what went wrong in a trivial example like this, but in a big program like gcc this can be very confusing. This reduces the usefulness of using abort in combination with -g and optimization. The optimization that causes the problem is crossjumping. If I compile with -O2 -fno-crossjumping I get the desired result. So rms's request is essentially to disable crossjumping of abort calls. Incidentally, we have already pushed crossjumping back from -O to -O2. If I use gcc-3.3, the example fails with -O -g. But with gcc-4, it works at -O -g and fails only at -O2 (or -Os) -g. Since -O -g works with current sources, perhaps this is a good enough solution. Or perhaps just asking people to use -fno-crossjumping is a good enough solution. Otherwise, we need to consider the merits of disabling an optimization to make debugging easier. This is a difficult choice to make, but at -O2, I'd prefer that we optimize, and suggest other debugging techniques intead of relying on the line numbers of abort calls. Such as using assert instead. I suppose there is yet another alternative, which is to extend the debug info to indicate that the single abort call is both line 5 and line 7, and then extend gdb to handle this gracefully, but this does not seem to be a practical solution, at least not a practical short term one. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Merging calls to `abort'
James E Wilson wrote:
To give this request a little context, consider the attached example.
This time actually attached.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
int
sub (int i, int j)
{
if (i == 0)
abort ();
else if (j == 0)
abort ();
else
return i * j;
}
int
main(void)
{
return sub (0, 10);
}
Re: Question about "#pragma pack(n)" and "-fpack-struct"
On Sat, 2005-03-12 at 21:00, feng qiu wrote:
> Is it difficult to modify the gcc sources if I want to use the both?
The tricky part might be defining what it means. There are at least 4
interacting features here, #pragma pack, attribute ((packed)), attribute
((aligned(X)), and -fpack-struct. Currently, -fpack-struct is defined
to have the same effect as attribute ((packed)) for all structures,
which in turn is equivalent to #pragma pack(1) for all structures. If
you want -fpack-struct to mean something else, then you need to define
how these features interact. This will probably mean splitting the
current TYPE_PACKED/DECL_PACKED fields into two, one which handles
pragma pack, one which handles -fpack-struct, and attribute((packed))
can perhaps go in which ever one makes more sense. Then you need to
modify all code that uses TYPE_PACKED/DECL_PACKED appropriately, which
may be messy.
It occurs to me to mention that you can get the result you want if you
use attribute ((aligned(2)) instead of pragma pack(2). That is better
than hacking up gcc.
struct TEST{
charx1;
intx2 __attribute__ ((aligned(2)));
};
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: `make uninstall' and GCC
Sam Lauber wrote: The gccinstall info says that `make uninstall' would open a can of worms. I don't get it. Why? The same paragraph gives one explanation. Gcc includes shared libraries. If you uninstall a copy of gcc, then everything compiled with that gcc will suddenly stop working (ignoring -static for the moment), which is bad. There are also other possible problems. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Root Node of AST
Rajesh Babu wrote: I am working with gcc-3.3.3, and I want to insert my module after construction of AST and before RTL generation. gcc-3.3 is not interesting for work like this. This stuff has already been obsoleted in current gcc sources. But if you insist on using out dated sources, look at expand_expr. Or start with the c_expand_body statement called from finish_function. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: PRE in GCC-3.3.3
Rajesh Babu wrote: I found that PRE is not done in gcc-3.3.3, though the code for doing PRE exists in source code. gcc-3.3 is not interesting for work like this. The PRE support in gcc-3.3 has already been effectively obsoleted by other work in current gcc sources, though it is still there. You failed to specify the target. The target often makes a big difference on whether optimizations are performed. I am assuming the target is ia64-linux. Your testcase incidentally is serious flawed. The varible c is both used while uninitialized, and set using an unitialized value. It doesn't make much sense to talk about compiler optimizations when you have a testcase that invokes undefined behaviour. The testcase is also flawed in that it takes the address of both a and b, forcing them into memory, and thus making optimization of them difficult, particularly in pre-gcc-4 sources. I seem to get the same behaviour from both gcc-3.3 and gcc-3.4. In neither case is the partially redundant expression eliminated. gcc-4 does perform the optimization. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: a problem about cross-compile for powerpc
邹琼 wrote: > ../../../source/gcc-4.0-20050109/gcc/config/rs6000/darwin.md:243: > unknown mode `V4SI' That is a snapshot that is over two months old. Snapshots are unsupported, and have a lifetime of less than a week, so this has been obsolete for almost 2 months now. If there is a problem here, it was probably already fixed a while ago. Try looking at more recent sources. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: false spam positive from gcc-patches
Thomas Koenig wrote: any reason why the message http://gcc.gnu.org/ml/fortran/2005-03/msg00282.html was rejected as spam from gcc-patches, yet accepted on the fortran list? See http://www.sourceware.org/lists.html#rbl-sucks which has a discussion of how the spam filters work, and how to get around them. Possible reasons 1) The address you posted from is subscribed to one mailing list but not the other (perhaps an alternate address is subscribed on the other list). 2) The address you posted from is on the allow list for one mailing list but not allow list of the other. By the way, I think it is a word of all caps in the subject line which triggers the spam filter, and "PR" is such a word, which is unfortunate. This is just a guess though. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: supporting --with-cpu=default32 option for x86_64
Nitin Gupta wrote: following lines were added in config.gcc in order to recognise --with-cpu=default32. But I dont understand , how it was actually made to default to 32-bit. The trick is to look at the default64 code, and note what default32 doesn't do that default64 does do. The code you quoted is only clearing with_cpu when default32/default64 are given, because these are valid options to the actual gcc code. These just mean "use whatever the default with_cpu value is". -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Suggestion for a fix to Bug middle-end/20177
Mostafa Hagog wrote: The question is: what is the correct fix for the longer term ? is it enough to mark the SMSed block dirty? or do we need also to keep the REG_DEAD correct in each basic-block separately? You either have to keep all REG_NOTES up to date, or call code that will recompute them. You can recompute REG_DEAD/REG_UNUSED notes by calling back into flow. This is presumably what happens when you mark the block dirty, so that would be a sufficient solution for REG_DEAD/REG_UNUSED. See for instance code in combine.c that updates REG_NOTES after combination. This is in distribute_notes. By the way, REG_UNUSED means that this instructions sets a register, and this value dies here. There are no uses of this register before the next set or the end of the function. Thus it holds register life info that is complimentary to REG_DEAD. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: RTL?
하태준 wrote: > where i get the impormation about code, log_links, reg_notes See the internals documentation, in the file gcc/doc/rtl.texi, or on the web at http://gcc.gnu.org/onlinedocs/gccint/Insns.html#Insns See also the sources for more info, as the docs may not be fully up to date, in particular the file rtl.h. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: PRE in GCC-3.3.3
Rajesh Babu wrote: The target I used is i686-linux. For the same example gcc-3.4.1 eliminated the redundant expression, where as gcc-3.3.3 didn't do it. I observed it by dumping RTL with -dG switch. I didnt get abt the flaw you were talking about. The optimization is done on the pseudo registers, where is the question of forcing into memory there. Your example has int c, d; d = c++ which is both a use of c while uninitialized, and a set of c to an uninitialized value. The rest of this isn't very interesting, as gcc-3.3 is way too old to be looking at optimizations. Looking at the RTL, I don't see the optimization being performed in gcc-3.4. I still see two adds for c. But since it already works in mainline I don't care. By the way, x86 is not a good target to use for looking at gcse performance, because of all of the condition code clobbers, which make it difficult for gcse to move instructions around. It will only eliminate a redundant add if it can convert it to a leal instruction which does not clobber the condition code register. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: CC0 to CCmode conversion
Denis Chertykov wrote: I think that sequence of compare + cond-jump will exists in any compiler pass. Combine can optimize away compares, if you have other instructions that set the condition code register to useful values. This optimization will only work correctly if instructions that set or clobber the cc are properly marked. If no instructions are marked as setting the cc (other than compares), then this will probably work, but you won't get any optimization from combine, and may get worse code than before. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Obsoleting more ports for 4.0.
Kazu Hirata wrote: ip2k This is an Ubicom cpu, and they maintain a GNU port in house. There are references to it on their web site, though I didn't see a convenient link to download it. Probably not much worth to the FSF version of this port if they aren't contributing patches to it. ns32k Everytime we have tried to get rid of ns32k, some NetBSD users have complained. There is still a maintained NetBSD port for this. http://www.netbsd.org/Ports/pc532/ There are probably only about a dozen working machines left in existence, though. Not really worth our trouble if they aren't interested in maintaining the gcc port themselves. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Suggestion for a fix to Bug middle-end/20177
Mostafa Hagog wrote:
Thanks for the information, what we were doing was to call
update_life_info_in_dirty_blocks, but for some reason this wasn't
sufficient to
mark a register dead (REG_DEAD note) when the register was defined in a
predecessor block and dies in the dirty block; we had to call
update_life_info
for all the blocks to mark that register as dead. Is there cases that we
know
about that such case could happen? is this means a bug in update_life_info
I am not sure I have enough info to answer this.
If you are moving instructions from one block to another, then you may
need a full life pass, which means not using UPDATE_LIFE_LOCAL. With
UPDATE_LIFE_LOCAL, we assume that the info on which registers are live
at the end of each block is still correct, and we just update info
within blocks, i.e. making sure REG_DEAD notes within a block are in the
right place, as this might have changed. But if you need changes to
global_live_at_{start,end} then you need to rerun a full life pass
without UPDATE_LIFE_LOCAL to recompute this info.
Otherwise, I am not sure what the problem might be. You might try
spending a little time figuring out how update_life_info works.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Suggestion for a fix to Bug middle-end/20177
Paul Schlie wrote: Steven Bosscher wrote: IIRC these notes are for CCO, and you have to move the CC setter and user together. - unless it can be guaranteed that the particular setter's cc, will be preserved (i.e. not corrupted by successive operations) prior to it's ultimate use; ... Steven was correct. cc0 is special. See the code. Actually I think SMS for CC0 targets is Just Silly to do at all ;-) - with the exception that it should be useful to eliminate otherwise unnecessary explicit comparison operations ... Likewise. But this will hopefully be moot soon if Ian succeeds in eliminating cc0. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: RFA: PR 19225
Dale Johannesen wrote: I'm interested in fixing this, but could use some help from somebody knowledgeable about how x86 EH is supposed to work. In particular, what's the expected relationship between SP at the point of a throwing call, and when it gets back to the landing pad? There is no direct relationship between the two SP values. If they are different, then there should be unwind info indicating the difference, and the unwinder should be applying those differences while unwinding. There is a statement to this effect in comment #3 from Andrew. However, looking at this, I am tempted to call it a bug in the defer pop optimization. The testcase works with -fno-defer-pop. This is something we only do for old and/or embedded targets that push/pop function arguments, so it wouldn't be noticable on most any system that a gcc developer would be using. It is probably much easier to fix the defer pop optimization than to fix the unwinder to handle this. An unwinder fix would allow us to keep this optimization though. Perhaps adding something to expand_calls like /* ??? Defer pop and unwinding don't work well together. */ if (flag_exceptions && ! (flags & ECF_NOTHROW)) NO_DEFER_POP; along with a corresponding OK_DEFER_POP later. Actually, looking at this, I am surprised how may NO_DEFER_POP calls we have without corresponding OK_DEFER_POP calls. I wonder if this optimization is already broken, in the sense that is it being accidentally disabled when it shouldn't be. Or maybe the code is just more obtuse than it needs to be. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: inefficient code output?
Stefan Strasser wrote: movl %ebx, -200(%ebp) movl %ebx, -196(%ebp) movl %eax, 4(%esp) movl -200(%ebp), %edx movl -196(%ebp), %ecx It is hard to say without a testcase, but my first guess would be reload inheritance and/or the post-reload cse pass. Reload may need to load/store something from a stack slot to satisfy a reload. If we have two instructions in a row that need the same reload, then reload inheritance will try to reuse the value. This may avoid loading it twice and/or storing then reloading a value. If reload inheritance is successful, it then tries to delete the now unnecessary load/store, but this is a complicated operation, and doesn't always succeed. So sometimes we end up with unnecessary loads/stores for partially deleted reloads. A similar thing might happen if post-reload cse succeeds in simplifying some code, but doesn't succeed in deleting the now unnecessary stack load/store. Deleting a stack slot store is difficult, as it requires memory alias analysis that probably isn't being done in reload and the post-reload cse passes. It is better to avoid creating them in the first place, which is why we have reload inheritance, and why reload is so complicated. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC3 to GCC4 performance regression. Bug?
Steve Ellcey wrote: Any optimization experts care to take a look at this test case and help me understand what is going on and if this change from 3.4 to 4.0 is intentional or not? Use the -da -fdump-tree-all options, and start looking at the dumps. The first thing I notice is that in the RTL .loop dump file, gcc-3.4 does interesting stuff, like loop invariant code motion and the do-loop optimization. However, gcc-4 reports only Loop at 81 ignored due to multiple entry points. Loop at 83 ignored due to multiple entry points. This seems to be sufficient to explain the slow down, as the gcc-3.4 RTL loop pass moves some loads out of the inner loop, and adds a special looping branch instruction. And none of this happens in mainline. So the problem seems to be that tree-ssa optimizations have confused the loop structure to the point that the RTL loop pass doesn't work anymore. That is a serious problem. I'm guessing, but I think the problem is that we have (note 81 22 83 NOTE_INSN_LOOP_BEG) (note 83 81 23 NOTE_INSN_LOOP_BEG) (code_label 23 83 24 2 13 "" [2 uses]) i.e. two loops are using the same code label. This is a problem, as now we have no place to put loop invariant instructions for either loop. We used to have code to ensure that each loop had its own code label. tree-ssa could perhaps be modified to preserve that property, but probably a better solution is to make loop.c smart enough to detect this case and fix it itself by splitting the code label into two. I'd suggest filing a bug report for this problem to make sure it gets fixed. As for why the testcase works when you delete the M field, in this case tree-ssa does the loop invariant code motion itself. We still don't get any RTL loop optimization, but now all we are missing is the br.cloop instruction, and that causes only a small performance loss. tree-ssa isn't in my purview, so I won't try to guess what might be wrong here. I'll only point out that the difference occurs in the lim (loop invariant motion) pass, which makes sense. This might be worth a second bug report. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 4.0 Status Report (2005-03-24)
Richard Henderson wrote: 19255 EH bug on IA32 when using heavy optimization Typo in pr number? I think that is supposed to be 19225, for which I have already suggested a solution though not a patch (disable deferred argument popping when a call can throw). It isn't marked critical though, so I don't know why it is on the list, unless perhaps Mark just changed the status to be not critical. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: What does --enable-altivec do?
Michael LeBlanc wrote: Does that option do anything except supply -maltivec implicitly? As explained in the install docs, it does two things, enables -maltivec by default, and enables -mabi=altivec by default. This option has been deprecated and removed in the upcoming gcc-4.0 release. The preferred solution is to configure for an altivec target instead, e.g. powerpc-linux-gnualtivec. I see we still have the install docs for --enable-altivec. I will remove them. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC3 to GCC4 performance regression. Bug?
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote: > I'd suggest trying -fmove-loop-invariants, and report a bug about > that instead if it does not move those loop invariants. We really > should move away from loop.c anyway. In general, yes, but we will probably always need some RTL loop optimizations. Lowering gimple to RTL may expose target dependent loop invariants that were not present in the gimple. Hence, we still need the RTL loop pass to work. There is also the issue of the special looping branches, which is a low level target dependent issue that is probably better handled in RTL than gimple. The -fmove-loop-invariants option can't fix this problem, and this results in a few percentage points of performance loss for this testcase. We need the RTL loop pass for this. There is also the more pragmatic problem that we are suffering user visible performance losses right now, and we shouldn't force users to wait for future tree-ssa enhancements to fix them when an apparently relatively simple RTL optimizer change can fix them. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC3 to GCC4 performance regression. Bug?
On Thu, 2005-03-24 at 16:39, Andrew Pinski wrote: > Jim you know that -fmove-loop-invariants enables the "new" RTL BB based > loop optimizer? This option was added back in 3.4.0. No, I don't, and I stupidly didn't bother to check. I thought he was talking about some tree-ssa option. I tried it, it doesn't help. It solves neither the loop invariant code motion problem nor the do-loop optimization problem. If we are going to be moving to the new RTL loop optimizer soon then fixing it only there would be acceptable. Otherwise, it probably would be good to fix it in the old RTL loop optimizer too. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: about gcc-4.1-20050327
zouq wrote: > i build a crosscompiler for gcc, abi=n32 gcc-4.1-20050327/configure > -target=mips64el-linux -prefix=/opt/gcc-4.1-20050327/ > -enable-languages=c --disable-shared make it will error with > config/mips/mips.c We need more info than what you have provided. In particular, we need to know exactly what the error message was. Please see http://gcc.gnu.org/bugs.html for info on how to report bugs. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: A plan for eliminating cc0
Steven Bosscher wrote: As far as I can tell, there is no architecture requirement that p1 and p2 must be a register pair (ie. p6,p7 or p2,p3, etc.), but that seems to be the only form that GCC can produce. Perhaps this was done this way to avoid insn patterns with two sets? It was done this way because no one has written real predication support yet. And in this context, ifcvt.c doesn't count, because it only has the simplest of possible predication support. In the absence of real predication support, the two predicates are always inverses of each other, and hence there is no advantage to treating them as separate registers. We need both predicates so we can reverse branches, but there is no reason why we would ever need to treat them as anything other than a register pair. Treating them as a register pair makes everything simpler, the md patterns, the support for reversing branches, the PR register allocation, etc. They look just like the condition codes available on other targets when we do things this way. When we have real predication support, the predicate register support in ia64.md will have to be generalized. Until then, it seems to be an unnecessary luxury. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: [rtl-optimization] Improve Data Prefetch for IA-64
Steven Bosscher wrote: OK, so I know this is not a popular subject, but can we *please* stop working on loop.c and focus on getting the new RTL and tree loop passes to do what we want? I don't think anyone is objecting to this. My answers in an earlier thread were a little confused because I didn't realize you were talking about the new RTL loop optimizer. I thought you were talking about the tree loop optimizers. I forgot the new RTL loop optimizer was there. I was only arguing for the existance of any RTL loop optimizer, of which the new RTL loop optimizer certainly qualifies. I would however make a distinction here between new development work and maintenance. It would be better if new development work happened in the new loop optimizer. However, we still need to do maintenance work in loop.c. If gcc-4 suffers a performance regression because of a bug in loop.c, then that bug should be fixed. That is why I was arguing for a loop.c bug fix in an earlier thread. Not to make loop.c better. Only to make loop.c work as well as it did in gcc-3.4, until such time that it can be replaced. reason why there is no profile information available before this old piece of, if I may say, junk runs, and it the only reason why a great many functions in for example jump.c and the various cfg*.c files can still not be removed. "outdated" is a better term than "junk". loop.c was written in a different era, under very different circumstances, and is rather good given the constraints of the time. It has served us well for a long time, but has now outlived its usefulness. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: about gcc-4.1-20050327
zouq wrote: > /home/cpu/source/gcc-4.1-20050327/gcc/config/mips/mips.c:3976: error: > structure has no member named `truthvalue_conversion' This is the info we needed. Looking at the ChangeLog file, I see that this was accidentally broken by Joseph Myers last week. I posted a followup to the patch on gcc-patches pointing this out. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Texinfo appears to be FUBAR.
Steve Kargl wrote: In trying to do "gmake dvi" in the build directory, the gfortran.texi eventually dies with I noticed something similar, though the error messages I get are quite different. I tried taking a look. There is a gfortran.log file that lists the errors. I had to type ^Z while texi2dvi was running so I could look at the /tmp/.../gfortran.texi file. All of the errors are for the @gcctabopt macro which has disappeared. This gets included via the doc/include/gcc-common.texi file. I have texinfo v4.6 installed. If I build texinfo v4.8 it works. The docs say we only need texinfo v4.2 or greater. Perhaps the docs need updating here. I haven't tried other texinfo versions. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: PR 20505
Nathan Sidwell wrote:
Bug 20505 is an ICE with -ggdb2. We have the following member
definition,
const int b::d = ((int)(&((b*)1)->c) - 1);
whose initializer used to be folded during construction to an INT_CST, but
now it doesn't -- fold cannot fold the complete expression. As
My inclination is to simply add an additional check in the dwarf outputter,
verifying that the initializer is indeed an INT_CST.
That is a simple solution, but it causes us to lose debug info.
Looking at output_constant in varasm.c, I see that it works because it
calls expand_expr to convert the initializer to RTL, and then emits the
constant RTL. We can solve the dwarf2out.c problem similarly. That
suggests a patch like the attached untested patch. This simplifies the
code, retains the debug info for this case, and even emits debug info
for some cases like const FP vars that we currently don't handle. There
is the drawback that we might hit an abort for unexpected cases, whereas
the current code just does nothing. If it is important to avoid this on
the gcc-4.0 branch, we could just add the expand_expr call, and then use
INTVAL and CONST_DOUBLE_{LOW,HIGH} instead of tree_low_cst and
TREE_INT_CST_{LOW,HIGH}. That should be safe. On mainline, I think we
should try supporting everything here and see what happens.
Looking at this further, I find it interesting that
tree_add_const_value_attribute is only called from one place in an else
stmt. The if stmt calls add_const_value_attribute. Following that, I
see that if we have a variable with no DECL_RTL but with a DECL_INITIAL,
then the exact same thing happens as what my patch does. We call
expand_expr to generate constant rtl. This happens in
rtl_for_decl_location. There is a check for INTEGER_CST and REAL_CST on
this path, but these aren't strictly necessary, and are now undesirable
if the front ends aren't simplifying constants for us as is the case
here. This seems to imply that my solution is the right approach, and
that other simplifications and bug fixes may be possible or desirable
here, but one problem at a time...
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
2005-03-29 James E Wilson <[EMAIL PROTECTED]>
* dwarf2out.c (tree_add_const_value_attribute): Call expand_expr
and add_const_value_attribute.
Index: dwarf2out.c
===
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.574
diff -p -p -r1.574 dwarf2out.c
*** dwarf2out.c 22 Mar 2005 23:18:42 - 1.574
--- dwarf2out.c 30 Mar 2005 01:49:07 -
*** tree_add_const_value_attribute (dw_die_r
*** 10130,10149
else
return;
! switch (TREE_CODE (type))
! {
! case INTEGER_TYPE:
! if (host_integerp (init, 0))
! add_AT_unsigned (var_die, DW_AT_const_value,
!tree_low_cst (init, 0));
! else
! add_AT_long_long (var_die, DW_AT_const_value,
! TREE_INT_CST_HIGH (init),
! TREE_INT_CST_LOW (init));
! break;
!
! default:;
! }
}
/* Generate a DW_AT_name attribute given some string value to be included as
--- 10130,10137
else
return;
! add_const_value_attribute (var_die, expand_expr (init, NULL_RTX, VOIDmode,
! EXPAND_INITIALIZER));
}
/* Generate a DW_AT_name attribute given some string value to be included as
Re: [m68k]: Trouble trying to figure out LEGITIMIZE_RELOAD_ADDRESS
Peter Barada wrote: I'd like to make the reload look like: (set (reg:SI y) (plus:SI (reg_SI 16) (const_int 32832))) (set (reg:DF x) (mem:DF (reg:SI y))) Reload already knows how to make this transformation, so it should not be necessary to resort to LEGITIMIZE_RELOAD_ADDRESS. This is only needed for target specific tricks that reload can not and does not know about. See the code in find_reloads_address with the comment /* If we have address of a stack slot but it's not valid because the displacement is too large, compute the sum in a register. The problem here seems to be that double_reg_address_ok is true, but you don't want it to be true. It can only be true if GO_IF_LEGITIMATE_ADDRESS accept REG+REG+4. Perhaps the problem here is that a double address reg is OK for integer loads, but not for FP loads, in which case the double_address_reg_ok logic in reloads needs to be generalized a bit. Maybe an array based on mode instead of a single variable? Or maybe just int and fp versions are good enough for now. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: gcc-3.3.3 ppc e500 - Abort of uic from Qt
Clemens Koller wrote: /[..]/qt-x11-free-3.3.4/bin/uic -L /[..]/qt-x11-free-3.3.4/plugins -embed designercore [lots of images/*.png's] -o qmake_image_collection.cpp make: *** [qmake_image_collection.cpp] Aborted make: *** Deleting file `qmake_image_collection.cpp' uic is dumping core. We can't really do anything about that, as that isn't part of gcc. We need a testcase that we can use to reproduce the problem, or evidence of an actual gcc problem. If this is a gcc miscompilation problem, and you are compiling with a high optimization level like -O2, you could try using -O or -O0 instead. You could try using a different gcc version. Maybe gcc-3.3.4 has a bug that isn't present in other earlier or later gcc-3.3.x versions. You could try debugging uic to figure out why it is failing. >BTW: What are the most current versions for a toolchain which generates >working and efficient code for the MPC8540 (ppc32, e500, spe)? There are people supporting the e500 target, so it should be working reasonably well in any gcc release. There is a special branch maintained for the e500 by Red Hat, which is called gcc-3_4-e500-branch. This can be checked out from our cvs repository. I don't know details about this branch other than what is on the web site. http://gcc.gnu.org/cvs.html#devbranches and scroll down to the Architecture-specific section. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: PCH and moving gcc binaries after installation
Dan Kegel wrote: Moving an installed gcc/glibc crosstoolchain to a different directory was not allowed for gcc-2.96 and below, I seem to recall, but became permissible around gcc-3.0. Moving trees around has worked for a long time, but it required manually setting the GCC_EXEC_PREFIX environment variable. Cygnus got this working reliably sometime in the early '90s I think. In gcc-3.0 and later, there is code (make_relative_prefix) that computes and sets GCC_EXEC_PREFIX for you, so now you no longer need to manually set an environment variable to make it work. It just works by default. Once GCC_EXEC_PREFIX is set, it overrides pretty much all of the builtin paths, and since GCC_EXEC_PREFIX is always set, either explicitly by the user, or implicitly by gcc, the builtin paths should be mostly irrelevant. As for how this interracts with PCH, that I can't answer. I haven't tried it. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: symbol_ref constants
Sanjiv Kumar Gupta wrote: But I don't want to allow expressions like (const:SI (plus:SI symbol_ref:SI) (const_int)) in the insn. How should I do that, do I need to implement LEGITIMATE_CONST_P () accordingly? Try making CONSTANT_ADDRESS_P reject the value. Though it still isn't clear why you are getting relocation errors. If addresses wrap around at segment boundaries, then this should just work fine. a-40 gets converted into a very large positive segment offset that then wraps around back to a when 40 is added to it. Perhaps the assembler/linker need some work to handle this correctly. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 4.1 bootstrap failed at ia64-*-linux
Zagorodnev, Grigory wrote: IA64 bootstrap failed at abi_check stage reporting undefined references from libstdc++ (see log at the bottom). This seems indirectly related to bug 20964. Mark's proposed fix to stop building abi-check at bootstrap time means the IA-64 bootstrap should now succeed. This testcase will still be broken, but now it will only be a make check failure instead of a make bootstrap failure. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: gcc 3.4.2
Levent Erbuke wrote: Is there a tool that retrieve which version of gcc was used to compile a lib or anything else ? It depends on the target, but use of strings in the .comment section is fairly common. Try objdump --section=.comment --full-contents There will be one string for every object file if the version strings are present. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: PR 20505
Nathan Sidwell wrote: Being conservative I'd go for my patch on 4.0 and yours (if verified) on mainline. I'm fine with that. Have you actually written a patch yet? I don't see one in the bug report or in gcc-patches. I found a complication with my patch (string constants) when bootstrapping, and I plan to fix it by reorganizing the code a bit, so my patch will definitately not be a good idea for the 4.0 branch when I am done. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GNU toolchain for blackfin processor
Vinayak Ghate wrote: Do we have GNU toolchain for blackfin processor?? Can anybody help me out in this regard?? There is no blackfin port in the FSF GCC sources. However, Analog Devices does maintain some gcc ports for their targets, and may contribute them to us in the future. See http://www.analog-devices.com for further info. See also http://blackfin.uclinux.org which is refered to by the Analog Devices web site. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: ia64 bootstrap failure with the reload-branch
Steven Bosscher wrote: ../../reload-branch/gcc/unwind.inc:313: error: Attempt to delete prologue/epilogue insn: (insn/f 137 136 138 0 ../../reload-branch/gcc/unwind.inc:285 (set (reg:DI 33 r35) (reg:DI 320 b0)) -1 (nil) (nil)) Reload is using registers without setting regs_ever_live. The IA-64 prologue code needs a temp register to save/restore b0, and it uses regs_ever_live to find one. Also, because we have variable size register windows, we need the regs_ever_live info to be accurate so we can set up the register windows properly. The problem happens in inherit_one_chain, but it looks like there are other similar places that may have the same problem. Ugly patch attached that gets me past this problem. We should probably get Bernd's opinion on how he thinks this should be fixed. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com Index: reload1.c === RCS file: /cvs/gcc/gcc/gcc/reload1.c,v retrieving revision 1.463.2.2 diff -p -p -r1.463.2.2 reload1.c *** reload1.c 20 Mar 2005 19:49:08 - 1.463.2.2 --- reload1.c 1 Apr 2005 00:05:53 - *** inherit_one_chain (struct inherit_chain *** 3682,3687 --- 3682,3691 head_rl->nregs = HARD_REGNO_NREGS (best_reg, head_rl->mode); head_rl->reginfo.regno = best_reg; head_rl->reginfo.allocated = 1; + /* ??? Need a set_reload_reg or equivalent call here? Also, everyplace else + in this file where the same construct appears? For now, just set + regs_ever_live manually. */ + regs_ever_live[best_reg] = 1; /* Extend lifetime of original reload. Set the LIVE_UNTIL_END flag so that following calls to compute_birth_death will preserve this
Re: ia64 bootstrap failure with the reload-branch
Steven Bosscher wrote:
Bootstrap with the reload-branch dies on ia64 in stage0 while
building unwind-ia64.c:
I needed one more minor patch to quiet a warning in reload.c, and I
couldn't help but notice that reload1.c is being compiled with -Wno-error.
Thhis got me all the way to a bootstrap compare failure, which I haven't
bothered to look at.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Index: reload.c
===
RCS file: /cvs/gcc/gcc/gcc/reload.c,v
retrieving revision 1.268.6.1
diff -p -p -r1.268.6.1 reload.c
*** reload.c18 Mar 2005 18:40:32 - 1.268.6.1
--- reload.c1 Apr 2005 02:33:48 -
*** static int refers_to_regno_for_reload_p
*** 236,242
static int
push_secondary_reload (int in_p, rtx x, int opnum, int optional,
enum reg_class reload_class,
! enum machine_mode reload_mode, enum reload_type type,
enum insn_code *picode)
{
enum reg_class class = NO_REGS;
--- 236,243
static int
push_secondary_reload (int in_p, rtx x, int opnum, int optional,
enum reg_class reload_class,
! enum machine_mode reload_mode,
! enum reload_type type ATTRIBUTE_UNUSED,
enum insn_code *picode)
{
enum reg_class class = NO_REGS;
Re: PR 20505
On Fri, 2005-04-01 at 00:38, Nathan Sidwell wrote: > Here it is, ok? The patch is OK. The ChangeLog entry should refer to INTEGER_CST instead of INT_CST. You are missing a ChangeLog entry for the testcase. The testcase is not portable, as I pointed out in the PR. Trying this on an x86_64-linux system, I get 27 "excess errors" failures. All of them are error: cast from 'int*' to 'int' loses precision Using long works better than int, but is still not fool proof, as there are targets where longs are smaller than pointers. Maybe we can rely on something like ptrdiff_t? -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GNU toolchain for blackfin processor
Vinayak Ghate wrote: Do we have GNU toolchain for blackfin processor?? Can anybody help me out in this regard?? I was mistaken. The Blackfin port has already been submitted, but not yet added to our source code repository. There is a chance that it may end up in the upcoming release, gcc-4.0. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 4.1 bootstrap failed at ia64-*-linux
Zagorodnev, Grigory wrote: How it is possible that recent cgraph changes affect ia64 compiler behavior? I see reclaimed callgraph differs on ia64 but not on ia32; therefore ia32/x86_64 compiler remains stable. This is presumably the same problem that is now PR 20717. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Problems using cfg_layout_finalize()
Grzegorz B. Prokopski wrote: If I do that I run into an infinite loop in fixup_reorder_chain() in its first for loop at: while (NEXT_INSN (insn)) << HERE insn = NEXT_INSN (insn); It looks like there is an undocumented assumption about insn-chains and the rbi->header and rbi->footer fields. Normally, all of the insns for a function are part of a single linked list. Blocks are numbered sequentially, so it is always true that the last insn of block N is followed by the first insn of block N+1. If blocks N and N+1 are separated, then you are supposed to split the insn chain, and set rbi->footer for block N, and rbi->header for block N+1. These header/footer fields are used to reconnect the insn chain when the block movement is done. That is from a quick look, and may not be entirely accurate. I haven't done extensive work with this code. I managed to isolate a case where moving a single BB would trigger this behaviour. (This is as far as I can tell by looking at the original code and matching BB's to source code positions. How do I get a dump of insns of a BB into some textual form? Is there a utility function for that?) There are macros in the .gdbinit file that is automatically loaded by gdb. You can use pr to print a single instruction. E.g. (gdb) print insn (gdb) pr You can use prl to print a list of N instructions. E.g. (gdb) print debug_rtx_count = 1000 (gdb) print get_insns () (gdb) prl will print 1000 instructions from the beginning of the function. This assumes that the insn-chain is intact, which isn't true during block reorg. You probably want to use something like BB_HEAD here. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: 4.0-20050319 / 4-020050402 build error due to --enable-mapped location
René Rebe wrote: ../../gcc/tree-cfg.c: In function `remove_bb': ../../gcc/tree-cfg.c:2062: error: invalid type argument of `unary *' This was fixed on mainline on March 7. Is --enable-mapped-location considered to be a functional in 4.0 ? Apparently no. The fixes have not been backported to the gcc-4.0 branch. Since enable-mapped-location is a new feature, breakage probably won't be considered a regression that needs to be fixed. It should be functional on mainline, but may not be checked very often. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: gcc4, static array, SSE & alignement
tbp wrote: Question: why do i get an unaligned array as soon as g++ (4.1.0 20050327, cygwin) finds out that it's static (i mean even if i try to fool it around a bit)? I would guess a limitation of cygwin binutils support, or perhaps of Windows itself. This seems to work fine on linux. If I compile a simple example using __alignof__, I see that the compiler is assuming 16-byte alignment. If I compile with -S, I see that the compiler is giving them 32-byte alignment (probably for better cache alignment). If I run objdump -x on the a.out file, I see that .bss section has 2**5 (32-byte) alignment. All is as it should be. We can't give a section more alignment than that supported by the OS, so if Windows only gives the bss and/or data sections 8 byte alignment, then variables in these sections can never have more than 8 byte alignment. A real bug report, as per http://gcc.gnu.org/bugs.html would be useful here, so we can check. In particular, a testcase to reproduce the problem, and exactly what you believe is wrong with the output. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Question about "#pragma pack(n)"
feng qiu wrote: > I want to modify the gcc source code,what should I do? Look at the c-pragma.c file, search for pack. Also see -fpack-struct in common.opt and fpack_struct in opts.c. Then expand your search from there. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Question about "#pragma pack(n)"
On Tue, 2005-04-05 at 21:20, feng qiu wrote: > In c-pragma.c file, #pragma pack(n) set the value of > "maximum_field_alignment". > And in opts.c file,-fpack-struct set "flag_pack_struct = 1" . > But I don't known the relation between them. Try using grep, as in "grep flag_pack_struct *.c" and "grep maximum_field_alignment *.c". > It seems that they relate to the four ariablesââ > DECL_ALIGN,DECL_PACKED,TYPE_PACKED,and TYPE_ALIGN in stor-layout.c file,but > what is the difference in them?Should I modify this file? If you really want to modify files, and submit a patch, you have to use current mainline sources. This stuff works differently on mainline than it does in the older sources you are looking at. We can't accept a patch based off of an older release. Yes, you are looking in the right place. TYPE_PACKED and maximum_field_alignment are the important ones for this particular problem. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Major bootstrap time regression on March 30
Steven Bosscher wrote: We have a bootstrap time regression since March 30. Bootstrap times on Diego Novillo's SPEC box went up from (an already high) 5500s to almost 8000s I tried looking at this, but I haven't been able to find any bootstrap time regressions. I've got a mainline tree checked out with -D2005-03-29 and one checked out with -D2005-04-01. When I bootstrap them, they take the same amount of time to build. Is it possible that something changed on Diego's machine? Such as a new binutils, or a new kernel, etc? Or maybe I'm looking at the wrong dates? You said between March 30 and March 31, so I figured Mar 29 and Apr 1 would be good enough to reproduce it. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: ia64 bootstrap failure with the reload-branch
On Thu, 2005-04-07 at 04:35, Bernd Schmidt wrote: > Try the patch below - does it fix the problem? OK, I will try it. This may take about 2 days. My lone IA-64 machine is busy doing other stuff at the moment. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Use normal section names for comdat group?
H. J. Lu wrote: Gcc 4,0 generates .section .gnu.linkonce.t._ZN3FooC1Ev,"axG",@progbits,_ZN3FooC1Ev,comdat for comdat group. Can gcc use .section .text._ZN3FooC1Ev,"axG",@progbits,_ZN3FooC1Ev,comdat instead? At least, there will be less characters for linker to process. I know of no reason why we must continue using .gnu.linkonce for targets that have proper comdat support. However, I don't think this will be an easy transition, because there are too many places that make assumptions about the fact that .gnu.linkonce has a special meaning. That might be an argument against even trying. For instance, in varasm.c, in default_function_rodata_section, we have /* For .gnu.linkonce.t.foo we want to use .gnu.linkonce.r.foo. */ if (DECL_ONE_ONLY (decl) && strncmp (name, ".gnu.linkonce.t.", 16) == 0) and this code fails if you remove the .gnu.linkonce from the section name. We'd need code to check for and handle a comdat section here. dwarf2out.c assumes that comdat sections for debugging start with .gnu.linkonce. There are likely many other places that need fixing also. There is also the possible issue that using .text.foo conflicts with the naming scheme used by the -ffunction-sections -fdata-sections options. What happens if we have two sections both named .text.foo, one of which is a comdat section, and one of which came from -ffunction-sections? We might still need to use a distinct prefix to make this work, though it doesn't have to be as long as .gnu.linkonce. And if we do add another prefix, some of the special code for .gnu.linkonce will have to be duplicated, in which case it might have been simpler to just stick with .gnu.linkonce in the first place. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: about alias analysis
zouq wrote: > i wonder whether there exists or not alias analysis for scalar variable, > array variable, even pointers. > thank you. Yes. See alias.c for alias analysis on RTL. See also tree-ssa-alias.c for alias analysis on trees. The latter is much more sophisticated. The latter hasn't been in a release yet. You need to look at either gcc-4.0 prerelease, or the mainline development sources. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Major bootstrap time regression on March 30
On Thu, 2005-04-07 at 17:34, Diego Novillo wrote: > Another thing, has our library code base (libjava, libstdc++) > grown significantly lately? I was doing full builds, except for Ada. I should have mentioned that. Ada doesn't get configured by default, and I haven't bothered to check why. I probably forgot to install the Ada compiler package. So I think this is a possibility only if the Ada library got suddenly bigger and slower to compile, and if you are including Ada in your builds. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Major bootstrap time regression on March 30
On Fri, 2005-04-08 at 16:36, Daniel Berlin wrote: > Jim works on a machine: Athlon64 3400+, with 1GB main memory, running SuSE 9.1 x86_64-linux.
Re: PowerPC sections ?
Charles J Gillan wrote: Is the GOT not sufficient to do this though ? I can’t see why it is necessary to define two new sections ? What goes into those sections ? The GOT is sufficient if you have a shared library loader that knows how to read ELF files and apply the relocations embedded within. The -mrelocatable option tries to make this easier for embedded targets by emitting code that does the relocations for you, and storing the relocation info in regular object file data sections. See the gcc/config/rs6000/eabi.asm file, in particular the __eabi_convert function and its callers, which uses the got2 and fixup sections to perform relocations when a program is loaded at a different address than it was linked for. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: HEAD regression: All java tests are failing with an ICE when optimized
Andrew Haley wrote: Oh, right. I wonder why this happens only with Java? Because Java defaults to -fnon-call-exceptions. Add -fno-non-call-exceptions and it will work. It looks to me like the REG_EH_REGION check in postreload-gcse.c is bogus. We can have these notes here with -fnon-call-exceptions, and we will have to do something about them. Perhaps just ignoring insns with a REG_EH_REGION note will work, which appears to be what gcse.c does. I haven't haven't really looked at the code to see if this is the proper solution though. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: RTL code
Rajkishore Barik wrote: Can someone tell me if there is a way to generate RTL code which does not include use and def of the same pseudo in the same insn? That depends on how you are generating RTL, but it should be pretty obvious that you can use gen_reg_rtx to generate a temp reg for use as a destination for most operations. Or maybe your question is how to get everyone else to generate RTL code this way? No, there isn't an easy way to do this. There are also some reasons why it is impossible to do it everywhere. RTL matches hardware instructions, and some targets have instructions that require that source and destination operands match. There are also some rtl operations that implicitly use and set the same register, such as bitfield inserts. Some targets have complex operations that may require rtl that explicitly sets and uses the same register in order to adequately describe. Etc. You can't fix all of these cases by splitting apart instructions, at least not without losing performance. There is also the issue of extended asms, which may use and set the same register. In general, gcc does already try to use temporary regs in many places when optimizing, because we often get better code that way. This is probably only true in very early rtl optimization passes though. In later ones, the temps will have already been optimized away. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: gcc for syntax check only (C): need to read source from stdin
Dave Korn wrote: [EMAIL PROTECTED] /gnu/testing/obj-HEAD> make check 2>&1 | tee check.log Always use "make -k check". Some testsuites exit with an error if one or more tests failed, and because this is the normal situation for almost all testsuites, this means the only way to get meaningful results is to use -k. You will still get a failure for the fixincludes testsuite, but it will be ignored, and the other testsuites will work. Or alternatively, run the ones you care about individually, e.g. "make check-target-libstdc++-v3" which will run only the libstdc++-v3 testsuite. Or alternatively, you can cd into the directories you care about, e.g. "cd gcc; make check-g++" which will run just the gcc C++ testsuite. Etc. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: internal compiler error at dwarf2out.c:8362
Martin Koegler wrote: tree type = TREE_TYPE (*node); tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type)); tree newtype = build_type_attribute_variant (type, attr); TYPE_MAIN_VARIANT (newtype) = TYPE_MAIN_VARIANT (type); TREE_TYPE (*node) = newtype; You shouldn't be trying to build your own types in a machine dependent attribute handler function. The compiler's type system is determined by front-ends mainly, and some middle-end infrastructure, and isn't your domain to mess with. This stuff is subject to change, at which point your code may break. The sensible thing here would be to give an error message if an attribute is misused. There are a number of subtleties in the type system relating to arrays, so it isn't surprising that you are having trouble with them. For instance, you can't apply some kinds of type modifiers to array types, they have to be applied to the array element types instead. I think the problem with your code is that you are setting TYPE_MAIN_VARIANT to point at the original type. TYPE_MAIN_VARIANT is only supposed to be used in the presence of type qualifiers like const and volatile, to point at the unqualified type. But you have no type qualifiers here, and hence TYPE_MAIN_VARIANT should point at itself. See the gcc internals docs for TYPE_MAIN_VARIANT which specifically mentions type qualifiers. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: FW: GNU Mailing Lists Question #1
Chris Miller wrote: Hi. I'm hoping you can help me with the questions in this e-mail and the one that follows. Bugs should be reported into bugzilla. Period. The old info is obsolete and should be ignored. See http://gcc.gnu.org/bugs.html Mailing list info can be found here: http://gcc.gnu.org/lists.html The old info is obsolete and should be ignored. We aren't interested in bug reports against gcc releases older than gcc-3.3. Any such bugs will be closed without further comment if the problem is already fixed in current releases. We are especially not interested in bug reports against proprietary gcc releases, where proprietary means any release not made by the FSF. If you have made any modifications to the gcc sources you are releasing, then we don't want the bug reports. Any such bugs will be closed with a comment telling the reporter to contact the vendor that produced their gcc release. See the tenth bullet at http://gcc.gnu.org/bugs.html#dontwant If you are making a proprietary release, there are a few things you should do to the gcc sources. I don't think we have a documented list of them, but I think there are only two main ones: a) Change the version number to indicate where it came from, e.g. something like "gcc 2.95 (lnxw)" instead of just "gcc 2.95". Try "gcc -v" on most any linux system for comparison. b) Change the message printed when an internal error is detected. Instead of mentioning the gcc.gnu.org address, it should point at an address inside lnxw.com. Where this message exists depends on the gcc version you have, which you didn't mention. Look at GCCBUGURL in system.h in gcc-2.95, look at bug_report_url in version.c in current releases. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: internal compiler error at dwarf2out.c:8362
Martin Koegler wrote: I changed the attribute handler to only return NULL_TREE in any case, but the result is still the same (using the same gcc core). But you are still creating the types in the attribute function right? If so, that is probably why you still have a problem. You mentioned that this works for all types except array types. Instead of trying to figure out why array types don't work, perhaps you should figure out why other types do work, and then maybe you can understand why array types don't work. Looking at this, I see that you have two array types, both with the same typename which points at the same type decl. It doesn't seem right for two different types to both claim to be the same typedef. That doesn't seem to be an issue though. I tried grepping the sources, and I see this same code appears in the avr and ip2k ports. That gives me a way to try to reproduce the problem with FSF sources. Avr doesn't support DWARF2, and ip2k is being obsoleted because it is unmaintained. These probably aren't very good examples to copy from. Anyways, I tried building ip2k-elf, changing your testcase to use progmem instead of eeprom, and it compiles OK. Perhaps your problem is already fixed on mainline, or maybe you have some other changes in your tree that are causing problems. I suggest you try looking at why the ip2k port works when yours doesn't. If you can produce an example that fails in the FSF tree, then I can try looking at this some more. Otherwise, it seems to be a bug in your port, and you will need to find the problem yourself. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: [m68k]: More trouble with byte moves into Address registers
Peter Barada wrote:
pp_pack.c:2220: error: unable to find a register to spill in class `ADDR_REGS'
pp_pack.c:2220: error: this is the insn:
(insn 5559 5558 5560 694 pp_pack.c:2144 (set (reg:SI 8 %a0 [1421])
(plus:SI (subreg:SI (reg:QI 1420) 0)
(const_int -32 [0xffe0]))) 121 {*addsi3_5200} (insn_list 5558
(nil))
You might want to look at CANNOT_CHANGE_MODE_CLASS, which can be used to
change how reload handles (subreg:SI (reg:QI)). That might help avoid
generating QImode ADDR_REG reloads in the first place.
But if they are generated, then you need second reloads to resolve them
as Ian mentioned. There is probably no way to avoid implementing this.
You should also look at MODES_TIEABLE_P, which may also help prevent
getting QImode ADDR_REG reloads.
Even if you fix both of these, you will probably still need the
secondary reload support for this case.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: internal compiler error at dwarf2out.c:8362
Björn Haase wrote: In case that one should not use machine specific atttributes, *is* there a standard way for GCC how to implement different address spaces? Use section attributes to force functions/variables into different sections, and then use linker scripts to place different sections into different address spaces. You can define machine dependent attributes as short-hand for a section attribute, and presumably the eeprom attribute is an example of that. The only thing wrong with the eeprom attribute is that it is trying to create its own types. It is not necessary to create new types in order to get variables placed into special sections. There is nothing wrong with the concept of having an eeprom attribute. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Cross Compile PowerPC for ReactOS
James Tabor wrote:
fp-bit.c:744: error: unrecognizable insn:
(call_insn:HI 53 49 59 0 fp-bit.c:743 (parallel [
(set (reg:SF 33 1)
(call (mem:SI (symbol_ref:SI ("__pack_f") [flags 0x41]
) [0 S4 A32])
(const_int 0 [0x0])))
(use (const_int 0 [0x0]))
(clobber (scratch:SI))
This needs to match one of the call_value patterns in the rs6000.md
file. Presumably the call_value_local32 pattern. The matching happens
in recog. You could put a breakpoint there, and try stepping through
the code to see what is wrong. You can print rtl by using the pr gdb
macro. E.g.
print insn
pr
call_value_local32 doesn't do much, so I'd guess it is the
current_file_function_operand predicate. You could try putting a
breakpoint there also.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: ppc32/e500/no float - undefined references in libstdc++ _Unwind_*
Clemens Koller wrote: /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' /usr/local/lib/nof/libstdc++.so.6: undefined reference to [EMAIL PROTECTED]' These functions should come from libgcc_s.so or libgcc_eh.a, depending on whether this is a shared or static link. Try checking to see which libgcc libraries are being linked in. Try adding -v to the compiler line, or even -Wl,--verbose to see what the linker is doing. Try running nm on the libgcc libraries to make sure they are OK. If you have multiple gcc versions installed, you might be accidentally linking in the wrong libgcc libraries. If you have libraries compiled with other gcc versions, it is possible that they are bringing in the wrong libgcc, from an older gcc release. Try using g++ to link instead of gcc. Somehow you are getting C++ libraries even though you seem to be linking C code, and using g++ for the link will make sure that the proper C++ libraries are linked in the proper order. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: Stack and Function parameters alignment
Petar Penchev wrote: I tried to use force_reg or PUT_MODE but it does nothing and PUSH AL, inc S remain. If nothing is happening, then that means the peephole isn't matching. The matching happens in peephole2_insns. You could try putting a breakpoint there and stepping through the code to see what happens. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: compile error for gcc-4.0.0-20050410
Guochun Shi wrote: make[1]: Entering directory `/home/gshi/gcc/gcc-4.0.0-20050410/build-i686-pc-linux-gnu/libiberty' make[1]: *** No rule to make target `../include/ansidecl.h', needed by `regex.o'. Stop. make[1]: Leaving directory `/home/gshi/gcc/gcc-4.0.0-20050410/build-i686-pc-linux-gnu/libiberty' It looks like you tried to build in the source directory. That is supposed to work, but we never test it, and it is known to have frequent problems. Try following the directions that say to configure in a separate directory. E.g. mkdir objdir cd objdir ../gcc-4.0.0-20050410/configure ... This is how we build it, and this is known to work. Since you already have one broken configure/build in the source directory, you probably need to rm -rf your current source/build tree, and extract a new source tree from the release tar ball. Building in a separate directory has the advantage that when something goes wrong, your source tree doesn't get messed up. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: The subreg question
Ling-hua Tseng wrote: > It's obvious that `movil' and `movim' are only access the partial > 16-bit of the 32-bit register. How can I use RTL expression to > represent the operations? As you noticed, within a register, subreg can only be used for low parts. You can't ask for the high part of a single register. If you have an item that spans multiple registers, e.g. a 64-bit value that is contained in a register pair, then you can ask for the SImode highpart of a DImode reg and get valid RTL. This works because the high part is an entire register. This isn't useful to you. Otherwise, you can access subparts via bitfield insert/extract operations, or logicals operations (ior/and), though this is likely to be tedious, and may confuse optimizers. There are high/lo_sum RTL operators that may be useful to you. You can use (set (reg:SI) (high: ...)) (set (reg:SI) (lo_sum (reg:SI) (...))) where the first pattern corresponds to movims, and the second one to movil. You could just as well use ior instead of lo_sum for the second pattern, this is probably better as movil does not do an add. You may want to emit normal rtl for an SImode move, and then split it into its two 16-bit parts after reload. This will avoid confusing RTL optimizers before reload. We have vector modes which might be useful to you. If you say a register is holding a V4QI mode value, then there are natural ways to get at the individual elements of the vector via vector operations. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: [RFC] warning: initialization discards qualifiers from pointer target type
Devang Patel wrote: warning: initialization discards qualifiers from pointer target type This warning can not be disabled using -Wno-cast-qual (or any other warning flags). Is it intentional ? It looks like we have been doing it this way since at least gcc-1.42. The same code is there, with no way to disable it, though the wording of the message is a little different. I didn't try looking back any farther than that. This seems rather unlikely to be an accident. Though of course, this doesn't mean that we can't have an option to control it. -Wno-cast-qual doesn't seem like the right choice, as there is no user cast here. Maybe something like -Wno-discard-qual, where -Wdiscard-qual is the default. I notice that these are pedwarns, not a warning as in the -Wcast-qual case, which means that the ISO C standard requires a diagnostic here. For this reason, it may not be wise to add an option to disable the warnings. You may lose portability to other compilers. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: internal compiler error at dwarf2out.c:8362
Martin Koegler wrote: I added to the i386 version the following code (using a unmodified gcc for the rest): With this change, I can reproduce the problem. I noticed that I get a failure for all types, not just array types. This is different than what you described earlier, but perhaps the difference is that we don't have the questionable code to create new types here. I debugged this a bit more. The situation seems to be this: 1) We create a first array type when we parse the array decl in the first line (build_array_type). 2) We create a second array type when handling the typedef (clone_underlying_type). This one gets TYPE_NAME set to the typedef, and DECL_ORIGINAL_TYPE of the typedef points to the first one. 3) We create a third array type when parsing the attributes. See the call to build_type_attribute_variant in attribs.c. This is a complete copy, so it still has the GROUP9_T TYPE_NAME. 4) We create a fourth array type when handling the second typedef. This gets the TYPE_NAME EGROUP9_T, and the typedef has DECL_ORIGINAL_TYPE set to point to the third array type. When we emit debug info, we emit debug info for the types used by the typedefs, which are the second and fourth one. The debug info for the second one is OK. The debug info for the fourth one runs into trouble. We follow DECL_ORIGINAL_TYPE to get the third array type, and then we follow TYPE_NAME to get the second array type, and then we notice that we already emitted debug info for this type. After we return, we double check to make sure we have debug info for this type, and fail, because this is not the same array type as we emitted earlier. I think the broken type is the 3rd one. I mentioned in an earlier message that you had two types with the same TYPE_NAME which was wrong. This is happening in build_type_attribute_variant. Clearing TYPE_NAME here seems to solve the problem, though I haven't done any testing to see if this is safe. Maybe a bug report to keep track of this info would be useful. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: GCC 4.0 RC2 Available
commented onMark Mitchell wrote: The changes that I anticipate between now and the final release are (a) documentation changes, (b) a patch for 20991, and (c) a possible patch for 20973. Other than that, I will only consider patches that fix egregious problems, like a fail to bootstrap on a primary platform. I put comments in PR 20973. It seems reasonable for a reload patch, i.e. only moderately dangerously unsafe as opposed to severely dangerously unsafe. However, there is a bigger issue for Itanium. The example has an uninitialized register read. On Itanium, this can result in a later NaT consumption fault if that uninitialized register happens to have the NaT bit set. That will result in a core dump. This problem will likely be extremely rare, as gcc doesn't have speculation support yet, and hence can't create NaT bits, but there are a few hand written glibc routines that use them. I think this is a serious problem for Itanium. This seems to be an unfortunate side effect of tree-ssa code to decompose structure references. The old rtl code (e.g. store_constructor) was careful to always initialize a structure to zero if it was in a register, so that we did not have any uninitialized register reads. The new tree-ssa code makes no attempt to do this. If this problem is fixed, then we should not need any reload patch. This can perhaps be fixed in flow by adding code to initialize registers that are used before they are set. We already have some code for this in initialize_uninitialized_subregs, but it doesn't handle the general case. Of course, trying to fix this at such a late stage might be just as risky as the reload patch. Tis a shame I didn't notice this earlier. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Re: The subreg question
Ling-hua Tseng wrote: James E Wilson wrote: I read the descriptions of (high:m exp) and (lo_sum:m x y) in the gcc internal manuls (Section 10.7 and 10.9). The last line of their descriptions confused me because they wrote "m should be Pmode". A doc bug. You only need Pmode if you are operating on an address. high was originally added for loading addresses on a risc, like a sparc, in which case you would have to have Pmode. However, it has proven useful in many other cases. The sparc.md file for instance has an SFmode pattern that uses high/lo_sum, for loading an SFmode constant into a general register. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
