A question about RTL output
Hello, This is a strange problem. Why an operantion that should be a 'xorsi3' format, yet it comes out with a 'scond' format. I have defined 'xorsi3' indeed. When I use the encluesive operantion '^', it is ok to emit 'xorsi3'. When I compile the libgcc, it is not ok in _pack_df.o. So what's the problem? Thanks. Eric.
[Fwd: Re: Problem with GNAT Ada floating-point image representation under HPUX]
Original Message
Subject: Re: Problem with GNAT Ada floating-point image representation
under HPUX
Date: Sun, 23 Oct 2005 10:43:12 +0200
From: .:SB:. <[EMAIL PROTECTED]>
To: Clarke, Carus V <[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
Good reading is "Programming in ADA 95 2nd Ed, John Barnes" Addison-Wesley.
It's not a question about the compiler, floating point variables are
always hardware dependent, this is why it's recommended to create an own
float package customized to your needs. And at the same time, you have
the text representation of the float in Float_IO Package.
Pag 40, Genericity
"The standard package for the input and output of floating point values
in text from is GENERIC with respect to the actual floating point type.
This is because it is needed a single package to cope with all the
possible floating types such as the underlying machine types Float and
Long_Float as well as the portable type My_Float"
Pag 596, Finale - Portability
"There is, however, one simple rule which should be followed. We should
always declare our own floating point types and not directly use the
predefined types such as Float."
Take a look to Float_IO package and you will realize it, check also
"Floating point types" pg 341.
Good luck,
Float are allways "interesting" when you are pressed by the boss :)
I'll allways have fear about planes... sorry :)
J.J.
Clarke, Carus V wrote:
> I have been using the gcc 3.4.4 GNAT compiler to compile an existing Ada
> program on an HP-UX 11 system.
>
> We have noticed that generated images of floating-point numbers often
> appear with the least-significant digit incremented by 1. Since the
> application is used in a calibration laboratory, this situation is not
> acceptable to the users. Below is some sample output, followed by a
> listing of the program that produced the output. This same program
> produces the expected output when compiled and run on a Windows machine,
> that uses the same revision (3.4.4 -- cygming special) of the compiler.
> The program also produces the expected output when compiled with the
> older GNAT-3.15p compiler on the HP-UX machine. Using gdb 6.3 to step
> through the program as it was running on the HP-UX machine showed that
> the Value attribute did correctly convert the string representation
> ("1.") to 1.0 for both Float and Long_Float cases.
>
> The build configuration for the compiler is:
>
> Reading specs from
> /site/sw/gcc-3.4.4/lib/gcc/hppa2.0w-hp-hpux11.11/3.4.4/specs
> Configured with: ../gcc-3.4.4/configure --prefix=/site/sw/gcc-3.4.4
> --with-gnu-as --with-as=/site/sw/gcc-3.4.4/bin/as --disable-nls
> --enable-languages=c,c++,ada --enable-threads=gnat
> Thread model: gnat
> gcc version 3.4.4
>
> And the as version is:
>
> GNU assembler version 2.15 (hppa2.0w-hp-hpux11.11) using BFD version
> 2.15
>
> I have also noted the same behavior with the gcc 4.0 GNAT compiler.
>
> Any suggestions or ideas would be appreciated.
>
> Thanks,
>
> Carus V. (Bud) Clarke
> [EMAIL PROTECTED]
>
>
> --
>
> Program output:
>
> The number's string representation is: 1.
> The image of the float value is: 1.1E+00
> Text_Io output for float value is:1.1
> The image of the long-float value is: 1.01E+00
> Text_Io output for long-float value is:1.001
>
>
> --
>
> Program code:
>
>
> -- File: test_float_image.adb
> -- Date: Oct. 20, 2005
>
>
> with Ada.Text_Io;
> with Ada.Float_Text_Io;
> with Ada.Long_Float_Text_Io;
>
> procedure Test_Float_Image is
>XSTR : constant String := "1.";
>XF : constant Float := Float'Value(XSTR);
>XL : constant Long_Float := Long_Float'Value(XSTR);
> begin
>Ada.Text_Io.Put ("The number's string representation is: ");
>Ada.Text_Io.Put (XSTR);
>Ada.Text_Io.New_Line;
>Ada.Text_Io.Put ("The image of the float value is: ");
>Ada.Text_Io.Put (Float'Image(XF));
>Ada.Text_Io.New_Line;
>Ada.Text_Io.Put ("Text_Io output for float value is: ");
>Ada.Float_Text_Io.Put (Item => XF,
> Fore => 4,
> Aft => 5,
> Exp => 0);
>Ada.Text_Io.New_Line;
>Ada.Text_Io.Put ("The image of the long-float value is: ");
>Ada.Text_Io.Put (Long_Float'Image(XL));
>Ada.Text_Io.New_Line;
>Ada.Text_Io.Put ("Text_Io output for long-float value is: ");
>Ada.Long_Float_Text_Io.Put (Item => XL,
> Fore => 4,
> Aft => 7,
> Exp => 0);
Re: gcc.dg/ipa/ipa-5.c
Andreas Jaeger <[EMAIL PROTECTED]> wrote on 20/10/2005 18:08:56: > > Hi Razya, > > you developed the following tests: > > 2005-10-12 Razya Ladelsky <[EMAIL PROTECTED]> > > * g++.dg/ipa/ipa-1.c: New test. > * g++.dg/ipa/ipa-2.c: New test. > * g++.dg/ipa/ipa-3.c: New test. > * g++.dg/ipa/ipa-4.c: New test. > * g++.dg/ipa/ipa-5.c: New test. > * g++.dg/ipa/ipa.exp: New file. > > Test 5 fails for me on Linux/x86_64: > > Executing on host: /builds/gcc/misc/gcc/xgcc -B/builds/gcc/misc/gcc/ > /cvs/gcc/gcc/testsuite/gcc.dg/ipa/ipa-5.c -O3 -fipa-cp -fdump-ipa- > cp -fno-show-column -S -m32 -o ipa-5.s(timeout = 300) > PASS: gcc.dg/ipa/ipa-5.c (test for excess errors) > FAIL: gcc.dg/ipa/ipa-5.c scan-ipa-dump-times versioned function 2 > FAIL: gcc.dg/ipa/ipa-5.c scan-ipa-dump-times propagating const 2 > > Any ideas what's broken? > > Andreas > -- > Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj > SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany >GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 > [attachment "attup4dv.dat" deleted by Razya Ladelsky/Haifa/IBM] Yes, I am aware of this problem. It does not fail for power and I'm trying to figure out why it fails for x86 architecture. It appears that the type of the constant being passed to a function having a short parameter, is an int while I expected it to be short. call to g : g (a, 3); definition of g : int g (float b, short c) I am not sure which part of the compiler is responsible to have the the types matched, but I think they should at this point. I am still working on this. Any ideas? Razya
Re: RFC: IPO optimization framework for GCC
* Sebastian Pop: > Steve Ellcey wrote: >> >> In the meantime I would be interested in any opinions people have on >> what level we should be writing things out at. Generic? Gimple? RTL? > > Or just dumping plain C code? This is almost what the pretty printers > are doing, and the way back to the compiler is already there ;-) Some front ends generate trees which cannot be generated by any C program. It might be possible to add some extensions (which would also help to come up with C test cases for bugs which are currently exposed by non-C front ends only), and this might even ease concerns that an ISO C backend might make it possible to use GCC as a library. But I think it's still better to use some binary serialized IL, just to discourage external reuse and make clear that it's an internal format, subject to frequent changes.
Re: gcc.dg/ipa/ipa-5.c
> It does not fail for power and I'm trying to figure out why it fails for > x86 architecture. SPARC is also affected, but in 32-bit mode only. -- Eric Botcazou
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
It looks like maybe a 64bit scalar-evolution issue - when I compile on
powerpc-linux with -m64, I also get the
"vect4.f:4: note: not consecutive access"
message.
This problem looks very similar to PR18403 which has been resolved a while
ago:
When compiling for 32bit, we get the following representation for the loop:
# i_2 = PHI ;
:;
D.505_38 = i_2 + -1;
D.506_39 = (*b_14)[D.505_38];
(*a_9)[D.505_38] = D.506_39;
i_41 = i_2 + 1;
if (i_2 == D.489_27) goto ; else goto ;
When compiling for 64bit, there is an extra cast:
# i_2 = PHI ;
:;
D.691_41 = (int8) i_2;
D.692_42 = D.691_41 + -1;
D.693_43 = (*b_16)[D.692_42];
(*a_10)[D.692_42] = D.693_43;
i_45 = i_2 + 1;
if (i_2 == D.674_29) goto ; else goto ;
>From the vectorizer dumps for the 32bit code, it looks like the
access-function computed for the index to array b is quite simple and the
dataref analyzer can easily analyze it (i.e. extact the step - 4B - and
conclude that the access is consecutive):
Created dr for (*b_14)[D.708_38]
base_address: b_14
offset from base address: () (i_25 * 4 + -4)
constant offset from base address: 0
base_object: *b_14
step: 4B
base aligned 0
misalignment from base:
memtag: TMT.11
In the 64bit case however, the vectorizer dumps show that the
access-function returned for the index to array b is much more compilcated
- the dataref analyzer doesn't seem to be able to extract the
evolution/step in this case, and concludes that the access is
non-consecutive:
Created dr for (*b_16)[D.692_42]
base_address: b_16
offset from base address: () ((int8) {i_27, +, 1}_2 *
4 + -4)
constant offset from base address: 0
base_object: *b_16
step: 0B
base aligned 0
misalignment from base:
memtag: TMT.11
Should we reopen PR18403?
thanks,
dorit
Toon Moene <[EMAIL PROTECTED]> wrote on 22/10/2005 12:18:57:
>This one gets vectorized for me, on powerpc-linux:
>
>~/mainline_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec
>-ftree-vectorizer-verbose=4 -S hilaram4.f90
>
>hilaram4.f90:4: note: Alignment of access forced using peeling.
>hilaram4.f90:4: note: Vectorizing an unaligned access.
>hilaram4.f90:4: note: LOOP VECTORIZED.
>hilaram4.f90:7: note: vectorized 1 loops in function.
>
>dorit
>
>
>> L.S.,
>>
>> This code:
>>
>> SUBROUTINE S(N)
>> DIMENSION A(N), B(N)
>> READ*,ISTART,ISTOP,B
>> DO I = ISTART, ISTOP
>> A(I) = B(I)
>> ENDDO
>> PRINT*,A
>> END
>>
>> when compiled thusly:
>>
>> $ gfortran -g -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=2 -
>> msse2 vect4.f
>>
>> draws the following "not vectorized" message:
>>
>> vect4.f:4: note: not vectorized: complicated access pattern.
>> vect4.f:4: note: vectorized 0 loops in function.
>
> I get the following, using the autovect branch compiler on
> x86_64-unknown-linux-gnu:
>
> vect4.f:4: note: = analyze_loop_nest =
> vect4.f:4: note: === vect_analyze_loop_form ===
> vect4.f:4: note: split exit edge.
> vect4.f:4: note: === get_loop_niters ===
> vect4.f:4: note: ==> get_loop_niters:() (D.813_29 - i_27) +
1
> vect4.f:4: note: Symbolic number of iterations is ()
> (D.813_29 - i_27) + 1
> vect4.f:4: note: === vect_analyze_data_refs ===
> vect4.f:4: note: get vectype with 4 units of type real4
> vect4.f:4: note: vectype: vector real4
> vect4.f:4: note: get vectype with 4 units of type real4
> vect4.f:4: note: vectype: vector real4
> vect4.f:4: note: === vect_analyze_scalar_cycles ===
> vect4.f:4: note: Analyze phi: HEAP.49_363 = PHI HEAP.49_381(7)>;
> vect4.f:4: note: virtual phi. skip.
> vect4.f:4: note: Analyze phi: HEAP.42_259 = PHI HEAP.42_268(7)>;
> vect4.f:4: note: virtual phi. skip.
> vect4.f:4: note: Analyze phi: HEAP.35_60 = PHI HEAP.35_312(7)>;
> vect4.f:4: note: virtual phi. skip.
> vect4.f:4: note: Analyze phi: i_1 = PHI ;
> vect4.f:4: note: Access function of PHI: {i_27, +, 1}_2
> vect4.f:4: note: step: 1, init: i_27
> vect4.f:4: note: Detected induction.
> vect4.f:4: note: === vect_pattern_recog ===
> vect4.f:4: note: === vect_mark_stmts_to_be_vectorized ===
> vect4.f:4: note: init: phi relevant? HEAP.49_363 = PHI 49_380(5), HEAP.49_381(7)>;
> vect4.f:4: note: init: phi relevant? HEAP.42_259 = PHI 42_268(5), HEAP.42_268(7)>;
> vect4.f:4: note: init: phi relevant? HEAP.35_60 = PHI 35_312(5), HEAP.35_312(7)>;
> vect4.f:4: note: init: phi relevant? i_1 = PHI ;
> vect4.f:4: note: init: stmt relevant? :
> vect4.f:4: note: init: stmt relevant? D.830_39 = (int8) i_1
> vect4.f:4: note: init: stmt relevant? D.831_40 = D.830_39 + -1
> vect4.f:4: note: init: stmt relevant? D.832_43 = (*b_10)[D.831_40]
> vect4.f:4: note: init: stmt relevant? (*a_16)[D.831_40] = D.832_43
> vect4.f:4: note: vec_stmt_relev
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
Dorit wrote: It looks like maybe a 64bit scalar-evolution issue - when I compile on powerpc-linux with -m64, I also get the "vect4.f:4: note: not consecutive access" message. This problem looks very similar to PR18403 which has been resolved a while ago: ... When compiling for 64bit, there is an extra cast: In the 64bit case however, the vectorizer dumps show that the access-function returned for the index to array b is much more compilcated - the dataref analyzer doesn't seem to be able to extract the evolution/step in this case, and concludes that the access is non-consecutive: ... Ah yes, this was a well-known issue in the days long before vectorization ... In 1997, Richard Henderson hacked g77 to generate 64-bit array indices on 64-bit machines to prevent these casts, which inhibited all sorts of run-of-the-mill induction variable analysis ... This is probably quite invasive. Cheers, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
> When compiling for 64bit, there is an extra cast: > In the 64bit case however, the vectorizer dumps show that the > access-function returned for the index to array b is much more > compilcated > - the dataref analyzer doesn't seem to be able to extract the > evolution/step in this case, and concludes that the access is > non-consecutive: > ... > > Ah yes, this was a well-known issue in the days long before vectorization > ... > > In 1997, Richard Henderson hacked g77 to generate 64-bit array indices > on 64-bit machines to prevent these casts, which inhibited all sorts > of run-of-the-mill induction variable analysis ... > > This is probably quite invasive. I thought we'd also fixed this in gfortran. Array indices should be 64-bit (aka gfc_array_index_type) on 64-bit targets. I guess you could also try -fdefault-integer-8, though that might break/pessimize other things. Paul
Re: Vectorizing HIRLAM NN.
Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor? I believe most people do understand these sentences now that FX has kindly provided a translation The importance of gfortran as the HIRLAM consortium is conserned (http://hirlam.knmi.nl) is not that we would use it in an operational setting (i.e., compiling the operational suite with it - we normally use the vendor supplied compiler for that). However, what gfortran enables is HIRLAM research by everyone who can install a GNU/Linux or other free software distribution. One of the things people keep forgetting is that there are still Universities in Europe (or Asia, or Africa) for which the license cost of proprietary Fortran compilers is prohibitive. This translates directly into fewer capable meteorological researchers working on HIRLAM. HIRLAM is not free software - but other Weather Prediction Systems are. Look at http://www.wrf-model.org, for instance. My younger brother (working at Wageningen University in the Meteorology department) already filed a bug report for gfortran based on his experiments compiling that code. There will be more examples. Build it, and they will come ... Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: [GCC] - new mirror site
On Sat, 15 Oct 2005, Frank Ned wrote: > I have space to mirror GCC. > > What I need do to contribut with GCC project? > > name of the server: absoluta.org > path to the GCC mirror: /gcc > country/city: Brazil/Brasília Thanks for the offer to mirror our site. http://absoluta.org/gcc does not seem to exist yet, and when I tried ftp://absoluta.org/gcc with Mozilla, I got an error message that said "530 login incorrect". Once you've set up the mirror, would you mind sending us a patch for http://gcc.gnu.org/mirrors.html? If you want to contribute to the GCC project in other ways, the following two URLs probably are the most useful ones: http://gcc.gnu.org/projects/ http://gcc.gnu.org/contribute.html Cheers, Gerald
@true in makefiles
According to a comment in line 2694 of gcc/Makefile.in, a dummy command like @true must be added to a rule to "force gnu make to recheck modification times.". But the GNU make manual says that a rule without a command simply states a dependency. In gcc, many of those "dependency only" rules depend on a stamp. A hack that may be used to remove the stamp itself is to use a pattern rule where the % matches just a single character (the . for example). Attached are three makefiles that illustrate the alternatives: Makefile1: uses a pattern rule Makefile2: uses a rule without a command Makefile3: uses a rule with a dummy command (the current way) All the three makefiles behave the same. I will try to change gcc's makefiles and, if all goes well, submit a patch (for 4.2). Rafael all: foo.c bar.h foo%c bar%h: gen touch foo.c touch bar.h all: foo.c bar.h foo.c bar.h: s-gen s-gen: gen touch foo.c touch bar.h touch s-gen all: foo.c bar.h foo.c bar.h: s-gen @true s-gen: gen touch foo.c touch bar.h touch s-gen
Re: A question about RTL output
Eric Fisher wrote: This is a strange problem. Why an operantion that should be a 'xorsi3' format, yet it comes out with a 'scond' format. Probably because it was optimized. If you want a better answer, you have to give us more info about what happened, such as a C testcase, and RTL dumps. But it is probably better if you look at this yourself. Generate debugging dumps, -da -fdump-tree-all, and then start looking. Presumably an XOR was generated at first, and then got optimized to an scond at some point. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: MIPS TLS relocation assembly code invalid from GCC-4.1...
Steven J. Hill wrote: GCC guts, but could not figure out why I get the symbolic register representations in the glibc compiled code and not in my stuff. Can Those aren't symbolic registers. Those are variable names. Try looking at the input file tst-tls10.c, and notice that it has variable names a1, a2, and a3. So somehow, in your output, the variable name a1 got replaced with the register name $5, which won't work. It is a very bad idea to try to use register names that are indistinguishable from variable names. One of them must have a prefix and/or postfix to avoid ambiguity. Maybe you have a macro somewhere that is trying to define a1 to $5? This should only be an issue if you are trying to preprocess .s output though. Or maybe you are using a compiler option to change register names? -mrname was removed in gcc-4.0, and I'm skeptical that this could cause the failure that you are seeing. Or maybe there is just a bug in the mips uclib tls support. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: RFC: future gfortran development and subversion
Daniel Berlin <[EMAIL PROTECTED]> writes: > Karl, Ben, have you ever seen a lengthy discussion indicating that > compressed and no-text base working copies are unlikely to happen? I once expressed the sentiment that compressed text bases were not as desirable as simply optional text bases, and said that since we were about to have the latter, it probably wasn't worth much effort to get the former. This was back when it looked like issue #525 (optional text bases) was on the verge of resolution. But I've always been enthusiastically in favor of optional text bases, like every other Subversion developer :-). Personally, I'm less excited about compressed text bases (especially if/when we have optional text bases), but I wouldn't stand in the way of compressed text bases, either. I couldn't quite tell from the given context exactly what the controversy was; it sounded like maybe there was just a miscommunication about the meaning of "raw dump" or "export" or something? Anyway, I hope this mail helps. Best, -Karl -- www.collab.net <> CollabNet | Distributed Development On Demand
A question about RTL output
>Probably because it was optimized. If you want a better answer, you >have to give us more info about what happened, such as a C testcase, and >RTL dumps. But it is probably better if you look at this yourself. >Generate debugging dumps, -da -fdump-tree-all, and then start looking. >Presumably an XOR was generated at first, and then got optimized to an >scond at some point. >-- >Jim Wilson, GNU Tools Support, http://www.specifix.com Thanks. And there is another question. I've been told that 'scond' operations are not obligatory defined. If they are not defined then they will use 'bcond' like. But while I omit 'scond', gcc will fail error that such operation rtl doesn't define. So why? Thanks again. Eric
Re: MIPS TLS relocation assembly code invalid from GCC-4.1...
Jim Wilson wrote: Those aren't symbolic registers. Those are variable names. Try looking at the input file tst-tls10.c, and notice that it has variable names a1, a2, and a3. So somehow, in your output, the variable name a1 got replaced with the register name $5, which won't work. *blush* I did not even think of/notice that. Thank you. Maybe you have a macro somewhere that is trying to define a1 to $5? This should only be an issue if you are trying to preprocess .s output though. Probably something like that. I will dig into this further. Or maybe there is just a bug in the mips uclib tls support. This most definitely a problem in uClibc TSL support. It worked in glibc, so I have to get it fixed for uClibc. Thanks for the extra eyes, Jim. -Steve
adding a new register type to i386.h, and add spill/fill support
Hello all, This is my first post! I'm already familiar with adding new intrinsics, and am familiar with several files: rtl.def - added new rtl types for new instructions simplify-rtx.c - return 0 in the simplify binary and simplify ternary operations for instructions with new rtl types i386.c - define new built-ins, expand new built-ins i386.h - added a new reg-class, defined new IX86_BUILTIN_* global defines i386.md - The lisp-type code that adds the new intrinsic I'm using GCC 3.3.4, but I doubt this will have consequence for what we're trying to accomplish. What I need to do now is define a new register type, and take it through the whole prcess, just like an xmm register would (spilling, reload.c, recog.c, etc., the unchartered territory). I've already added the new type to i386.h, however, I think I'm missing something in the #define REG_CLASS_CONTENTS section. Could anyone point me to more documentation about what each bit means? We need to add a new register type, and extend the # of existing registers. Extending the # of a register seems easy, but it's unclear to me if it has been done right since I don't know what each bit set in the REG_CLASS_CONTENTS define is. >From then the next steps would be adding full support to incorporate using the new type in intrinsics, etc. Any help would be appreciated tons! Tyler __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: A question about RTL output
Eric Fisher <[EMAIL PROTECTED]> writes: > Thanks. And there is another question. I've been told that 'scond' > operations are not obligatory defined. If they are not defined then > they will use 'bcond' like. But while I omit 'scond', gcc will fail > error that such operation rtl doesn't define. So why? It shouldn't. What is the actual error message? Ian
Re: gcc.dg/ipa/ipa-5.c
Razya Ladelsky <[EMAIL PROTECTED]> writes: > It does not fail for power and I'm trying to figure out why it fails for > x86 architecture. > It appears that the type of the constant being passed to a function having > a short parameter, is an int while I expected it to be short. > > call to g : g (a, 3); > definition of g : int g (float b, short c) > > I am not sure which part of the compiler is responsible to have the the > types matched, but I think they should at this point. Sounds like TARGET_PROMOTE_PROTOTYPES. Ian
A question on alias analysis
Hi , I am overwhelmed with the jargon and world of alias analysis and different kinds of it. I was wondering if some one can help me with this simple question. Is deciding if a pointer is pointing to what segment (heap/otherwise) a simpler problem than exactly deciding the points to set? thanks Shrey
A question about RTL output
>It shouldn't. What is the actual error message? > >Ian Such as follows, dp-bit.c: In function `__pack_d': dp-bit.c:435: error: unrecognizable insn: (insn 33 32 34 0 dp-bit.c:167 (set (reg:SI 159) (ltu:SI (reg:SI 158 [ .class ]) (const_int 2 [0x2]))) -1 (insn_list 32 (nil)) (nil)) dp-bit.c:435: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate.
Re: @true in makefiles
Rafael Ávila de Espíndola <[EMAIL PROTECTED]> writes: > According to a comment in line 2694 of gcc/Makefile.in, a dummy command like > @true must be added to a rule to "force gnu make to recheck modification > times.". > > But the GNU make manual says that a rule without a command simply states a > dependency. > > In gcc, many of those "dependency only" rules depend on a stamp. A > hack that may be used to remove the stamp itself is to use a pattern rule > where the % matches just a single character (the . for example). The cases you have to look at are the ones with move-if-change. You have to make sure that if the file does not change, none of the dependencies are considered to have changed. For example in multilib.h: s-mlib; @true s-mlib: $(srcdir)/genmultilib Makefile ... $(SHELL) $(srcdir)/../move-if-change tmp-mlib.h multilib.h $(STAMP) s-mlib we need the property that if multilib.h changes, everything that depends upon it gets rebuilt. If genmultilib or Makefile changes, we must try rebuilding multilib.h. However, if multilib.h does not then change, then things that depend upon multilib.h should not get rebuilt for that reason. The @true is necessary so that make checks whether the timestamp of multilib.h changed before deciding that it will rebuild things that depend upon multilib.h. Can you restate your plan based on that, showing examples which use move-if-change? Thanks. Ian
Re: adding a new register type to i386.h, and add spill/fill support
Tyler Anderson <[EMAIL PROTECTED]> writes: > I've already added the new type to i386.h, however, I > think I'm missing something in the #define > REG_CLASS_CONTENTS section. Could anyone point me to > more documentation about what each bit means? We need > to add a new register type, and extend the # of > existing registers. Extending the # of a register > seems easy, but it's unclear to me if it has been done > right since I don't know what each bit set in the > REG_CLASS_CONTENTS define is. Well, there is documentation in the internals manual, of course. Each bit in each entry in REG_CLASS_CONTENTS corresponds to a particular register. Which register it means is target specific, but you can figure it out based on, e.g., REGISTER_NAMES. For example, for the i386, bit 0 is ax, bit 1 is dx, etc. Ian
Re: A question about RTL output
Eric Fisher <[EMAIL PROTECTED]> writes: > dp-bit.c: In function `__pack_d': > dp-bit.c:435: error: unrecognizable insn: > (insn 33 32 34 0 dp-bit.c:167 (set (reg:SI 159) > (ltu:SI (reg:SI 158 [ .class ]) > (const_int 2 [0x2]))) -1 (insn_list 32 (nil)) > (nil)) > dp-bit.c:435: internal compiler error: in extract_insn, at recog.c:2083 > Please submit a full bug report, > with preprocessed source if appropriate. You have to find out where that instruction came from. gcc doesn't just make this sort of thing up. It was generated from something in your backend--a pattern in your .md file or explicit code in your .c file. This is done relatively easily in gdb by doing break make_insn_raw if cfun->emit->x_cur_insn_uid == 33 which should give you the creation of the above insn. Then walk up the stack to see what called it. Ian
