Re: Matching Constraints and Predicate
On Mon, Aug 23, 2010 at 6:43 PM, Ian Lance Taylor wrote: > > This also makes no sense. The operand predicate should test whether the > value is acceptable. The constraints should tell the register allocator > where the value should go. The paragraph you quoted is saying that the > operand predicate should restrict the value as much as possible to > ensure that the constraints will match. The paragraph is not saying > that you should test the register class of a register in the operand > predicate. > Thanks for clearing this up. -- PMatos
mov arguments are the same
Hello, In a rule like (set (match_operand 0 ...) (match_operand 1 ...)) I sometimes have operand0 equal to operand1, as in rtx_equal_p(operand[0], operand[1]) == 1. This generates a move between the same location (same as a nop). Is there a reason for getting this and is it up to me to handle it or this is just the result of some problem with my md file? I am in gcc4.4.4. Cheers, -- PMatos
nobits for named section
Hello,
I came across an issue regarding named section and nobits. In
the following example, I expected the c is placed is placed
in a section named .smemdata and nobits is set for the section
since "c" is initialized to zeros.
int a = 0;
int b = 2000 * 512;
static int c[(200 * 512)] __attribute__((section(".smemdata")));
void foo()
{
c[0] = 0;
}
Using both trunk x86_64 and arm-elf compilers, I found .smemdata
has progbits flag instead of nobits. Is this a bug?
Cheers,
Bingfeng
Re: mov arguments are the same
"Paulo J. Matos" writes: > In a rule like > (set (match_operand 0 ...) > (match_operand 1 ...)) > > I sometimes have operand0 equal to operand1, as in > rtx_equal_p(operand[0], operand[1]) == 1. > This generates a move between the same location (same as a nop). > > Is there a reason for getting this and is it up to me to handle it or > this is just the result of some problem with my md file? I am in > gcc4.4.4. Moves between the same register are normally eliminated by a loop at the end of reload(). Does your processor support memory-to-memory moves? I don't think anything will explicitly eliminate those, though I'm also not sure why they would be created in the first place. I'm surprised that it happens, but I don't know what would cause it. In particular I don't know that it is a problem in your MD file. You'll have to find out where they are coming from. Ian
Re: nobits for named section
"Bingfeng Mei" writes:
> I came across an issue regarding named section and nobits. In
> the following example, I expected the c is placed is placed
> in a section named .smemdata and nobits is set for the section
> since "c" is initialized to zeros.
>
> int a = 0;
>
> int b = 2000 * 512;
> static int c[(200 * 512)] __attribute__((section(".smemdata")));
>
> void foo()
> {
>c[0] = 0;
> }
>
> Using both trunk x86_64 and arm-elf compilers, I found .smemdata
> has progbits flag instead of nobits. Is this a bug?
I don't think I would call it a bug; it's more like a feature which has
not been implemented. gcc would have to record for each user defined
section whether there are any variables initialized to non-zero values.
It currently does not do that. Using SHT_PROGBITS always works, though
I understand it is not ideal for your scenario.
Ian
Improving gengtype (for plugin support notably) - how to get a rather big patch accepted?
Hello All Jeremie Salvucci and me Basile are working on improving gengtype. Our patch is still buggy [curious people might retrieve it from http://starynkevitch.net/Basile/gengtype-r163335-24august-2010.diff but I will remove that 267Kytes file of 9278 lines in a few days, and that file is a *buggy* patch against trunk r163335 and it should be cleaned & corrected before submission] and not ready yet for proposal to gcc-patches@ Today, our patch is still buggy (Jeremie worked more than a month on it, and I did work a few weeks on it with him) and not entirely complete. However, both Jeremie and me are very scared that, even when it will be ready and sent to gcc-patches@, our patch will not be reviewed by people legitimately able to OK it and will be completely ignored (actually, this happened to us before e.g. http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02178.html etc). It is extremely important for us (and particularly for me Basile & for GCC MELT) to have this patch accepted in 4.6, since it enables plugin to use GTY & the Ggc garbage collector. So far, the only way a plugin [like MELT] could add its own GTY-ed data is by running gengtype with both the GCC build and source entire trees, a requirement against every packaging principles and very uncommon (As Diego told once, it is a "dirty hack"). We were kindly told in private emails (from Diego & from Laurynas) that to increase the chances to get a patch accepted, it should be sliced in small pieces. However, I don't understand well how practically we could slice our patches (especially since the small http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02178.html has been essentially ignored, which gives me the impression that few people care about gengtype; so no matter if a gengtype patch is large or small, I am afraid it won't be reviewed!). First, a few technical questions: * what is a sequence of related small patches? Is it an ordered set of patches to apply in succession? By what exact set of commands (assuming a GNU/Linux system). Does a latter patch in that sequence apply to the trunk, or to the trunk updated by previous patches? * what is the preferred way of obtaining a sequence of small patches? svn diff -x -p gives one big *.diff file! Should we split it by hand? Are there other tools producing a sequence of small patches? Then, more specifically about our gengtype work. The bulk of our patch is a quite big set of routines to write the state of gengtype into a textual file, and to read it again. We ensure that the state is well persisted by having the build process first write the state file using build/gengtype -S $(srcdir) -I gtyp-input.list -w gtype.state this command just write gtype.state file of a bit less than 800Kbytes. It is a textual file in Lispy syntax (its lexer is taken from MELT). Then the build process reads that gtype.state file and generates all the usual gengtype-generated files without reading any other [e.g. GCC source] file [today we still have bugs!] by running build/gengtype -r gtype.state This should produce the same behavior that current trunk's gengtype. In other words, our gengtype generates exactly the same code as today! An hypothetical plugin would probably run gengtype -r gtype.state -P gt-plugin.h plugin*.c [perhaps some more options would be needed] and the gtype.state file will actually be installed in the plugins directory or in some other GCC installation subdirectory. I hope people do understand that our main motivation is to get plugin support in gengtype into gcc-4.6. The main way I see to split our patch in two pieces is to have a new file gengtype-state.c which would contain all the state reading & writing routines. However, our patch also added some improvements to gengtype itself (honestly, both Jeremie & me believe that gengtype.c is the worse source code we ever studied inside GCC; its quality seems much lower that that of the main GCC part, i.e. the middle-end files). We had to add minor improvements such as * the ability to pass program options to GCC. That is exactly the http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02178.html and following patch, and it has been ignored. * we removed the ugly hack that the set of languages is hardcoded in file path strings, just before the string itself. Now, input_file is a structure containing both the bitmask and the file name. * we replaced the clumsy sequence of string compares in get_output_file_with_visibility to compute the output file for a given input file by a regular-expression rules machinery. We now have a small sequence of rules, each containing a regular expression to match the input file name, and replacement strings for output_name & for_name files, and an additional action routine to improve or replace them. * we cleaned up a little bit some code pieces that we did not understand (but the generated C code is untouched). However, most of our changes are related and I am not sure we could post meaningful, inde
http://gcc.gnu.org/install/specific.html maybe should mention memory settings for OpenBSD
Possibly a note for: http://gcc.gnu.org/install/specific.html under OpenBSD. or just for the mail archives: Building a *slight* fork of 4.5.1 on OpenBSD/x86 4.7 I hit gcc -c -g -O2 -static -DIN_GCC -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute \ -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5/gcc -I../../gcc-4.5/gcc/. \ -I../../gcc-4.5/gcc/../include -I../../gcc-4.5/gcc/../libcpp/include \ -I/home/jay/dev2/cm3/m3-sys/m3cc/I386_OPENBSD/./gmp \ -I/home/jay/dev2/cm3/m3-sys/m3cc/gcc-4.5/gmp \ -I/home/jay/dev2/cm3/m3-sys/m3cc/I386_OPENBSD/./mpfr \ -I/home/jay/dev2/cm3/m3-sys/m3cc/gcc-4.5/mpfr \ -I/home/jay/dev2/cm3/m3-sys/m3cc/gcc-4.5/mpc/src \ -I../../gcc-4.5/gcc/../libdecnumber \ -I../../gcc-4.5/gcc/../libdecnumber/dpd -I../libdecnumber \ -I/usr/local/include insn-attrtab.c -o insn-attrtab.o cc1: out of memory allocating 304988696 bytes after a total of 0 bytes gmake: *** [insn-attrtab.o] Error 1 This was not a problem with 4.3.0 or 4.3.5. I don't know about 4.4.x. We skipped them, just because we are slow and lagging. I couldn't get ulimit to do anything as non-root. I do have swap. I changed these from 512 to 768, probably not all of them necessary: # pwd /etc # grep 768 login.conf :datasize-max=768M:\ :datasize-cur=768M:\ :datasize-cur=768M:\ and then I can proceed. System probably doesn't have much RAM, maybe only 512MB, so that could be where the previous values came from. I had never touched them. Smaller amounts of RAM seem "more normal" these days to pack more virtual machines onto one physical system. (Though this just an old laptop, not a virtual machine.) - Jay
Re: Improving gengtype (for plugin support notably) - how to get a rather big patch accepted?
Basile Starynkevitch writes: > * what is a sequence of related small patches? Is it an ordered set of > patches to apply in succession? By what exact set of commands (assuming > a GNU/Linux system). Does a latter patch in that sequence apply to the > trunk, or to the trunk updated by previous patches? An ideal sequence of patches is a series of patches which may be applied in order. At each stage the tree should be buildable. The patches don't have to be independent--they can be applied in a specific order--but they should each work. > * what is the preferred way of obtaining a sequence of small patches? > svn diff -x -p gives one big *.diff file! Should we split it by hand? > Are there other tools producing a sequence of small patches? You should make copies of the source tree and work out the diffs step by step. Do not try to break apart a big diff file. > However, our patch also added some improvements to gengtype itself Improvements are desirable, but if it is all possible you should separate these improvements from your other work. It is very hard to review patches which combine different unrelated ideas in a single diff. Ian
Re: Improving gengtype (for plugin support notably) - how to get a rather big patch accepted?
On 08/24/2010 07:38 PM, Basile Starynkevitch wrote: > * what is the preferred way of obtaining a sequence of small patches? > svn diff -x -p gives one big *.diff file! Should we split it by hand? > Are there other tools producing a sequence of small patches? http://savannah.nongnu.org/projects/quilt Bernd
gcc-4.4-20100824 is now available
Snapshot gcc-4.4-20100824 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100824/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 163528 You'll find: gcc-4.4-20100824.tar.bz2 Complete GCC (includes all of below) MD5=56cca79bcc60a674e5763be7e7849a28 SHA1=8e997fa0837d59e310b6e57da2c3b07d6e2ce84b gcc-core-4.4-20100824.tar.bz2C front end and core compiler MD5=035a77dbe84a7060e97dd8ed98b5424a SHA1=cbd6700196635b767b8092b0ac6c3cd204078e03 gcc-ada-4.4-20100824.tar.bz2 Ada front end and runtime MD5=416d72dc7f86d591691a6fdd10c4bed6 SHA1=e893059b3fce6a32432d17d90804c4e9d94f01cc gcc-fortran-4.4-20100824.tar.bz2 Fortran front end and runtime MD5=43384efe3e2a5cebb33aa1316e22e120 SHA1=a141fc8907cfdcddc75d5edda184247103683414 gcc-g++-4.4-20100824.tar.bz2 C++ front end and runtime MD5=af710edfc0ff22bb695a020f95a2b42b SHA1=0339972f1bba9c3b527a055ed473393e645a9682 gcc-java-4.4-20100824.tar.bz2Java front end and runtime MD5=a105a5d1dfcd2b5c6738ee590a1aad29 SHA1=2c33af6285253cc447774c92257d1ac913904085 gcc-objc-4.4-20100824.tar.bz2Objective-C front end and runtime MD5=45a29083e9526f30842198a12f0324f8 SHA1=6d518b515d880fb8a207a589ba557bd9d12278c1 gcc-testsuite-4.4-20100824.tar.bz2 The GCC testsuite MD5=104d0764ef1d81110164a578bc115f95 SHA1=2b6fc1d18ace434fedc88adc7de4e7c293ce275a Diffs from 4.4-20100817 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Change macro SHIFT_COUNT_TRUNCATED to target hook TARGET_SHIFT_COUNT_TRUNCATED?
Hello, I have a problem about the definition of SHIFT_COUNT_TRUNCATED. MIPS is a SHIFT_COUNT_TRUNCATED target, and has it defined as 1. While loongson-specific vector insns are not SHIFT_COUNT_TRUNCATED. That means that the macro depends on the machine mode. One simple resolution may be, #define SHIFT_COUNT_TRUNCATED (TARGET_LOONGSON_2EF ? 0 : 1) but this will disable the common optimization for loongson target. Another way is to use a target hook to handle this problem, but this requires many changes. I'd like to ask suggestions for this. Thanks, Mingjie
Re: Improving gengtype (for plugin support notably) - how to get a rather big patch accepted?
On Tue, 2010-08-24 at 15:19 -0700, Ian Lance Taylor wrote:
>
> > However, our patch also added some improvements to gengtype itself
>
> Improvements are desirable, but if it is all possible you should
> separate these improvements from your other work. It is very hard to
> review patches which combine different unrelated ideas in a single diff.
We only improved some minor points of gengtype when we had bugs related
to code that we found difficult to understand or to read. In particular
* replacement of the kludge of putting a language bitmask four bytes
before the path name of input files with a real structure for input
files.
* replacement of the get_output_file_with_visibility code with a
sequence of regular-expression rules.
None of these patch is unrelated to our main work of adding persistency
to gengtype. We had to make these improvements to make the whole thing
work.
A big thanks for your comments.
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: Improving gengtype (for plugin support notably) - how to get a rather big patch accepted?
2010/8/24 Basile Starynkevitch : > Hello All > > Jeremie Salvucci and me Basile are working on improving gengtype. Our > patch is still buggy [curious people might retrieve it from > http://starynkevitch.net/Basile/gengtype-r163335-24august-2010.diff I was meaning to take a look to get an idea what the patch is doing, but it arbitrarily changes indentation in otherwise-untouched places. Not that it matters now, as you are not submitting it, but I believe it is easier to always work within code formatting rules than to properly format only before submission. Other than that, I can only agree with what Ian advised for you. -- Laurynas
