Question about rs6000 zero_fp_constant predicate
Hello, I want to create a rtx which will fit the description of the following operand. (taken from selv2sf4 instruction in the rs6000/paired.md machine description) (match_operand:SF 4 "zero_fp_constant" "F") I am not sure how to create such zero const_double rtx and I appreciate help regarding this. Thanks, Revital
Re: Question about rs6000 zero_fp_constant predicate
> I want to create a rtx which will fit the description of the following > operand. (taken from selv2sf4 instruction in the rs6000/paired.md machine > description) > > (match_operand:SF 4 "zero_fp_constant" "F") > > I am not sure how to create such zero const_double rtx and I appreciate > help regarding this. CONST0_RTX (SFmode) -- Eric Botcazou
Re: PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]
On Tue, 28 Aug 2007, Mark Mitchell wrote: > Dave Korn wrote: >>> I do think that generating the same code, independent of host system, is >>> a very important property of GCC's design, just like generating the same >>> code independent of whether or not we're compiling with -g. >> Can the SC please consider adding these requirements explicitly to >> the list of "Design and Development Goals" in the mission statement? >> Or would it make more sense as part of the development methodology, or >> the portability section of the gcc-specific coding conventions? > I don't think this needs to be part of the mission statement; it's more > of a technical nitty-gritty than that. But, I think putting into the > coding conventions is a good idea. Seconded. Dave, want to give it a try? ;-) Gerald
Coding conventions -- command line option vs command-line option
And now to the most important issue of all to address before we can release GCC 4.3.0. ;-) In our current documentation we have both "command-line option" and "command line option". Like other such cases, we should make a choice and document this in codingconventions.html. I am willing to take care of that, and also adjusting our web pages accordingly. The question now is: which of the two variants shall we go for? Gerald
RE: Coding conventions -- command line option vs command-line option
On 17 September 2007 00:35, Gerald Pfeifer wrote: > And now to the most important issue of all to address before we can > release GCC 4.3.0. ;-) > > In our current documentation we have both "command-line option" and > "command line option". Like other such cases, we should make a choice > and document this in codingconventions.html. > > I am willing to take care of that, and also adjusting our web pages > accordingly. The question now is: which of the two variants shall we > go for? > > Gerald Hyphenated. It's not a line option of a command, it's an option of a command-line. cheers, DaveK -- Can't think of a witty .sigline today
RE: PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]
On 17 September 2007 00:28, Gerald Pfeifer wrote: > On Tue, 28 Aug 2007, Mark Mitchell wrote: >> Dave Korn wrote: I do think that generating the same code, independent of host system, is a very important property of GCC's design, just like generating the same code independent of whether or not we're compiling with -g. >>> Can the SC please consider adding these requirements explicitly to >>> the list of "Design and Development Goals" in the mission statement? >>> Or would it make more sense as part of the development methodology, or >>> the portability section of the gcc-specific coding conventions? >> I don't think this needs to be part of the mission statement; it's more >> of a technical nitty-gritty than that. But, I think putting into the >> coding conventions is a good idea. > > Seconded. Dave, want to give it a try? ;-) > > Gerald Yep, but I have a bit of backlog, won't be until later this week. cheers, DaveK -- Can't think of a witty .sigline today
Trap floating-point exceptions?
Under Linux, gcc/g++-compiled code happily continues running after producing NAN and INF. Often it is time-consuming to backtrack to the actual source of the numerical problems. In addition, such problems may go undetected for some time, which can cause all kinds of confusion. Other platforms stop after a floating-point exception (e.g. HP's Tru64 Unix with cc/cxx), or support customizations of FPE behavior via environment variables (e.g. SGI's old IRIX). Is something like this possible with gcc/g++ under Linux? Thanks! Ralf Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
Re: Trap floating-point exceptions?
On Sun, 2007-09-16 at 20:51 -0700, Ralf W. Grosse-Kunstleve wrote: > Under Linux, gcc/g++-compiled code happily continues running after > producing NAN and INF. Often it is time-consuming to backtrack to the > actual source of the numerical problems. In addition, such problems may > go undetected for some time, which can cause all kinds of confusion. Yes, NaNs are quiet by default. > Other platforms stop after a floating-point exception (e.g. HP's Tru64 Unix > with cc/cxx), or support customizations of FPE behavior via environment > variables (e.g. SGI's old IRIX). Is something like this possible with > gcc/g++ under Linux? This really has very little to do with GCC -- this list is for GCC development. Please try asking on the gcc-help mailing list, or a C programming list. Cheers, Ben
Should -ftrapv check type conversion?
I've been looking at -ftrapv and some simple cases it doesn't work right in. (I've got a patch coming soon to address one case where __addvsi3 libcalls and the like get optimized away in RTL.) I see a few reports in Bugzilla, many marked as duplicates of PR 19020 though they cover a few different cases, which have me wondering about what the scope of -ftrapv ought to be. (I'm assuming 32-bit int and 16-bit short below, for simplicity.) 1) What about conversions to signed types? unsigned int x = 0x8000; int y = x; /* trap? */ You get a negative number out of this if you define the conversion as wrapping twos-complement style, but I believe the spec says it's undefined. It's not so much "overflow" from an arithmetic calculation as "out of range", but isn't that what the signed- overflow errors come down to, results that are out of range for the type used to represent them? 2) Conversions to narrower signed types? signed int x = 0xf; signed short y = x; /* trap? */ It seems to me that a trap here would be desirable, though again it's an "out of range" issue. However, a logical extension of this would be to possibly trap for "*charptr = x & 0xff" or "(char)(x & 0xff)" on a signed-char configuration, and that's probably pretty common code. 3) What about narrower-than-int types? signed short a = 0x7000, b = 0x7000, c = a+b; Technically, I believe the addends are widened to signed int before doing the addition, so the result of the addition is 0xe000. If the result is assigned to an int variable, there's no undefined behavior. Converting that to signed short would be where the overflow question comes up, so this is actually a special case of #2. 3) Is Fortran 90 different? PR 32153 shows tests in Fortran for 1-, 2-, 4-, and 8-byte types. I know very little about the Fortran 90 spec, but if it doesn't say the narrower values get widened as in C, then -ftrapv should definitely cause traps for signed short or signed char arithmetic, even if we don't do it for the C type conversion cases above. Ken
libstdc++-v3/include/precompiled weirdness
I've recently noticed that every time I build GCC, the source files in the libstdc++-v3/include/precompiled directory have their modification timestamps updated. Anyone know what's going on here? Ollie
Re: GCC 4.3.0 Status Report (2007-09-04)
Mark,
> Kai Tietz wrote:
>
> >> Kai, why is your change making OUTGOING_REG_PARM_STACK_SPACE accept a
> >> FUNCTION_DECL, rather than a FUNCTION_TYPE? I'd think that all
> >> calling-convention predicates ought to be looking at the type to
support
> >> calling through function pointers?
> >
> > This macro is used also in builtin's and libcalls subject where the
> > FUNC_DECL is a null reference. Also in most places the FUNC_DECL is
> > allready present. To avoid duplicate code to check and get the
FUNC_TYPE
> > by FUNC_DECL, I choose to pass the function declaration.
>
> I'm sorry -- that doesn't really answer the question I was trying to
> ask. To be clear, if we're calling through a function pointer, we still
> need to be able to do the right thing, and in that case we don't have a
> FUNCTION_DECL. So, I don't understand how you can have a macro to
> control the calling convention that accepts a FUNCTION_DECL; I would
> think it would have to accept a FUNCTION_TYPE.
Sorry, I think I missed your question. To make the macro
OUTGOING_REG_PARM_STACK_SPACE accepting a FUNCTION_DECL, there is no
special reason for it. I deceided this to make it accepting a
FUNCTION_DECL to avoid the fndecl to fntype conversion in middle-backend.
In some cases there is no fntype nor a valid fndecl and (a NULL value),
but there is the FUNCTION_DECL type allready present, therefore I choose
the FUNCTION_DECL type instead of the FUNCTION_TYPE. I think, I used it to
be according to the REG_PARM_STACK_SPACE macro. If this is a serious
problem, of course I can move this to a FUNCTION_TYPE. Are there some
special needs to have here FUNCTION_TYPE ?
Cheers,
i.A. Kai Tietz
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
--
OneVision Software Entwicklungs GmbH & Co. KG
Dr.-Leo-Ritter-Straße 9 - 93049 Regensburg
Tel: +49.(0)941.78004.0 - Fax: +49.(0)941.78004.489 - www.OneVision.com
Commerzbank Regensburg - BLZ 750 400 62 - Konto 6011050
Handelsregister: HRA 6744, Amtsgericht Regensburg
Komplementärin: OneVision Software Entwicklungs Verwaltungs GmbH
Dr.-Leo-Ritter-Straße 9 – 93049 Regensburg
Handelsregister: HRB 8932, Amtsgericht Regensburg - Geschäftsführer:
Ulrike Döhler, Manuela Kluger
