Re: Type-punning
Herman Geza <[EMAIL PROTECTED]> writes:
[...]
> What is the correct way to do this:
>
> void setNaN(float &v) {
> reinterpret_cast(v) = 0x7f81;
> }
>
> without a type-prunning warning? I cannot use the union trick here
Why? Won't the following work?
void setNaN(float &v) {
union { float f; int i; } t;
t.i = 0x7f81;
v = t.f;
}
-- Sergei.
Re: [M16C] : 20 bit data access
Hi DJ,
>> From the above, I think I like this plan:
Please ignore my earlier post on this topic. We have modified the
proposed solution to incorporate your suggestions. We would be glad if
you could verify it again.
By default all the constant variables will be stored in the far memory
('.frodata' section) and will be accessed using "LDE" instruction. The
non-initialized non-constant variables will be stored in near memory
('.nbss' section) and will be accessed using "MOV" instructions. The
initialized non-constant variables will be stored in near memory
('.ndata' section) and will be accessed using "MOV" instructions.
* By default, all the constant variables will be placed in the far
memory. They will be accessed using LDE instructions ('.frodata'
section)).
* New attribute "near" will be added. This attribute will be used for
the latest M16C targets that have 4K/8K flash in near Memory.
* Constant variables specified with the attribute "near" will be placed
in a section ".nrodata" (near memory) and will be accessed using "MOV"
instruction.
* By default, non-constant initialized variables will be placed in near
memory.
* By default, non-constant non-initialized variables will be placed in
near memory.
* New attribute "far" (to use external memory for non-constant data
storage) will be added.
* Non-constant non-initialized variables specified with the attribute
"far" will be placed in a section ".fbss" (far memory).
* Non-constant initialized variables specified with the attribute "far"
will be placed in a section ".fdata" (far memory).
* LDE/STE instructions will be used to access the non-constant variables
specified with the attribute "far".
* MOV instructions will be used to access the constant variables
specified with the attribute "near".
* Default linker script will be modified for placing the default section
'.nbss', '.ndata' and '.nrodata' in near memory and '.fbss', '.fdata'
and '.frodata' in far Memory.
* Separate libraries will be used for R8C and M16C targets.
* As the libraries will be built without any attribute, all the constant
data in library will be accessed using LDE instructions. Similarly,
non-constant non-initialised and non-constant initialised data in
library will be accessed using MOV instructions.
Please comment on the above proposed solution.
Regards,
Naveen.H.S.
KPIT Cummins Infosystems Ltd,
Pune (INDIA)
~~
Free download of GNU based tool-chains for Renesas' SH, H8, R8C, M16C
and M32C Series. The following site also offers free technical support
to its users. Visit http://www.kpitgnutools.com for details.
Latest versions of KPIT GNU tools were released on June 1, 2007.
~~
Extending RTL expansion and CG with a new operation
Hello
I am extending the backend of GCC 4.1 with a new operation which maps
directly from a keyword in the language. So far I extended the frontend
and middleend in order to handle this new keyword. I managed to generate
the GIMPLE form and a valid CFG and a RTL object for this keyword.
Basically this keyword is handled as a jump-like instruction within the
RTL language.
Within the backend, I updated the following files to support this new
operation which is a kinda specific jump with a condition 'cre'.
- tree.def: the tree code for the keyword
- rtl.def: my new rtl operators
- optabs.h / .c: declaration of operators tables for tree-to-rtl
translations
- expr.c: expansion of trees into RTL expressions
- I also extended the files alpha.c/.d and alpha.md which the
architecture I target
- jump.c: handle the condition of my new jump
- dojump.c: handle the new jump I define
The 'expansion' is performed correctly (the RTL file is valid) and the
'cg' stage gives the following error:
-
kerneltest.c:22: error: unrecognizable insn:
(jump_insn 26 25 29 3 (set (pc)
(create_body_after (cre (reg:DI 75)
(const_int 0 [0x0]))
(label_ref 13)
(pc))) -1 (nil)
(nil))
kerneltest.c:22: internal compiler error: in extract_insn, at recog.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
-
Basically it says the new isns I added have not been recognized. Within
the function 'extract_insn', the function 'recog_memoized is called. The
code can be found in the file "recog.h" (cf following).
---recog.h--
static inline int
recog_memoized (rtx insn)
{
if (INSN_CODE (insn) < 0)
INSN_CODE (insn) = recog (PATTERN (insn), insn, 0);
return INSN_CODE (insn);
}
#endif
-
The function 'recog' is coded in a file 'insn-recog.c' which is
generated at bootstrap-time by the file 'genrecog.c'
Does anyone have a clue for solving the problem? I am really open to any
suggestions. ;-)
Thanks in advance,
Thomas
Re: Gcc trees
Revital1 Eres wrote: I work with Gcc trees to modify c++ original code and dont find and i need documentation about trees because the web isnt enought information. Where are docs about gcc trees and macros to access it? In GCC wiki you may find useful links: http://gcc.gnu.org/wiki (like GCC internal) wow. I was looking for info about the profile-arcs. (see post on gcov) GCC internal - "13 Control Flow Graph" Is this what you mean with trees? I want to understand how the graph in the .gcno files is generated. I need to know this because I'm using this graph to calculate complexity measures. Eddy
Re: m68k bootstrap problem
Roman Zippel wrote:
> Hi,
>
> On Wed, 20 Jun 2007, I wrote:
>
>
>> Index: gcc/df-problems.c
>> ===
>> --- gcc/df-problems.c(revision 125811)
>> +++ gcc/df-problems.c(working copy)
>> @@ -1574,7 +1574,7 @@
>>/* Call-clobbered registers die across exception and call edges. */
>>/* ??? Abnormal call edges ignored for the moment, as this gets
>> confused by sibling call edges, which crashes reg-stack. */
>> - if (e->flags & EDGE_EH)
>> + if ((e->flags & EDGE_EH) || (e->flags & EDGE_SIBCALL))
>> bitmap_ior_and_compl_into (op1, op2, df_invalidated_by_call);
>>else
>> bitmap_ior_into (op1, op2);
>>
>
> Adding the patch below seems to make reg-stack happy, so this may be a way
> to fix the edge information.
>
> bye, Roman
>
> Index: gcc/gcc/reg-stack.c
> ===
> --- gcc.orig/gcc/reg-stack.c
> +++ gcc/gcc/reg-stack.c
> @@ -2316,6 +2316,12 @@ subst_stack_regs (rtx insn, stack regsta
>if (NOTE_P (insn) || INSN_DELETED_P (insn))
> return control_flow_insn_deleted;
>
> + if (SIBLING_CALL_P (insn))
> +{
> + CLEAR_HARD_REG_SET (regstack->reg_set);
> + return control_flow_insn_deleted;
> +}
> +
>/* If this a noreturn call, we can't insert pop insns after it.
> Instead, reset the stack state to empty. */
>if (CALL_P (insn)
>
so how are you coming with the 68k?
kenny
Re: Type-punning
On Jun 22, 2007, at 1:41 AM, Sergei Organov wrote:
Herman Geza <[EMAIL PROTECTED]> writes:
[...]
What is the correct way to do this:
void setNaN(float &v) {
reinterpret_cast(v) = 0x7f81;
}
without a type-prunning warning? I cannot use the union trick here
Why? Won't the following work?
void setNaN(float &v) {
union { float f; int i; } t;
t.i = 0x7f81;
v = t.f;
}
__builtin_nan isn't sufficient?
-Chris
Re: Type-punning
Sergei Organov wrote:
Herman Geza <[EMAIL PROTECTED]> writes:
[...]
What is the correct way to do this:
void setNaN(float &v) {
reinterpret_cast(v) = 0x7f81;
}
without a type-prunning warning? I cannot use the union trick here
Why? Won't the following work?
void setNaN(float &v) {
union { float f; int i; } t;
t.i = 0x7f81;
v = t.f;
}
As far as I know, this is guaranteed to work with GCC. But it is not
kosher according to language standards, so other compilers might dislike
it. On the other hand, other compilers are not guaranteed to optimize
the call to "memcpy" out either.
Type punning has been disallowed regardless of disguise at least since
Fortran77, when compiler writers realized it had become evil. However,
in my opinion, there's a big difference between a useful little trick
like the union above and the horrible memory overlays that the Fortran77
standard tried to help disambiguate.
Silvius
Dataflow issues in the MIPS backend.
As noted in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32437#c5 > I'm not surprised that converting it to an unspec_volatile stops > us from deleting the instruction, but that wasn't really my concern. > > As I said earlier, several other ports use top-level unspecs (rather than > unspec_volatiles), and it appears that after the dataflow merge, that construct > is no longer allowed. Thus I think we should first nail down whether this > is a deliberate change. If it is (and I can see that it might be), > then I think we should change the RTL generators so that top-level > unspecs are not allowed in define_insns. I do not think we should the > MIPS port until we have established what the new rules are. > > (This isn't an issue about dataflow being more accurate per se; > the old code could also have deleted top-level unspecs with no > register dependencies, if it had thought that doing so was allowed.) I would appreciate it if one or more dataflow maintainers were to opine on the correctness of the patch in the bug report and to address Richard's concerns. Thanks, David Daney
Re: Type-punning
Chris Lattner <[EMAIL PROTECTED]> writes:
> On Jun 22, 2007, at 1:41 AM, Sergei Organov wrote:
>
>> Herman Geza <[EMAIL PROTECTED]> writes:
>>
>> [...]
>>
>>> What is the correct way to do this:
>>>
>>> void setNaN(float &v) {
>>> reinterpret_cast(v) = 0x7f81;
>>> }
>>>
>>> without a type-prunning warning? I cannot use the union trick here
>>
>> Why? Won't the following work?
>>
>> void setNaN(float &v) {
>> union { float f; int i; } t;
>> t.i = 0x7f81;
>> v = t.f;
>> }
>
> __builtin_nan isn't sufficient?
... and there a also
-- Function: double nan (const char *TAGP)
-- Function: float nanf (const char *TAGP)
-- Function: long double nanl (const char *TAGP)
The `nan' function returns a representation of NaN, provided that
NaN is supported by the target platform. `nan
("N-CHAR-SEQUENCE")' is equivalent to `strtod
("NAN(N-CHAR-SEQUENCE)")'.
The argument TAGP is used in an unspecified manner. On IEEE 754
systems, there are many representations of NaN, and TAGP selects
one. On other systems it may do nothing.
in GNU libc, and the manual says they are C99 standard functions.
-- Sergei.
Re: m68k bootstrap problem
Hi,
On Fri, 22 Jun 2007, Kenneth Zadeck wrote:
> > Index: gcc/gcc/reg-stack.c
> > ===
> > --- gcc.orig/gcc/reg-stack.c
> > +++ gcc/gcc/reg-stack.c
> > @@ -2316,6 +2316,12 @@ subst_stack_regs (rtx insn, stack regsta
> >if (NOTE_P (insn) || INSN_DELETED_P (insn))
> > return control_flow_insn_deleted;
> >
> > + if (SIBLING_CALL_P (insn))
> > +{
> > + CLEAR_HARD_REG_SET (regstack->reg_set);
> > + return control_flow_insn_deleted;
> > +}
> > +
> >/* If this a noreturn call, we can't insert pop insns after it.
> > Instead, reset the stack state to empty. */
> >if (CALL_P (insn)
> >
> so how are you coming with the 68k?
I started the bootstrap with my change and it works fine now, the tests
are still running but so far there is no dataflow related problem. :)
I'll drop my patch, the live information for an abnormal edge isn't really
important anymore assuming the right thing is done for last call insn in
that block. reg-stack could make use of it, but I'll leave that to someone
else... :-)
bye, Roman
Re: [M16C] : 20 bit data access
> By default all the constant variables will be stored in the far memory
> ('.frodata' section) and will be accessed using "LDE" instruction. The
> non-initialized non-constant variables will be stored in near memory
> ('.nbss' section) and will be accessed using "MOV" instructions. The
> initialized non-constant variables will be stored in near memory
> ('.ndata' section) and will be accessed using "MOV" instructions.
No, by default constants are in .rodata and non-constants are in
.data/.bss. Always. The big difference is that on the m16c, .rodata
is above 64k and LDE will be used to access it, but it's still called
.rodata.
ONLY if the user specifies "near" or "far" attributes will anything be
placed in .n* or .f*; this is an override. Those sections will always
be in near or far space (er, it's acceptable to put .f* in near memory
if the chip doesn't *have* far memory, of course).
Also, we need to support the user specifying both near/far *and* a
section override.
> * By default, all the constant variables will be placed in the far
> memory. They will be accessed using LDE instructions ('.frodata'
> section)).
.rodata, but ok. Assumed m16c only for LDE to .rodata.
> * New attribute "near" will be added. This attribute will be used for
> the latest M16C targets that have 4K/8K flash in near Memory.
Any target can use "near" or "far" attributes. It's up to the linker
script to decide where they're mapped.
> * Constant variables specified with the attribute "near" will be placed
> in a section ".nrodata" (near memory) and will be accessed using "MOV"
> instruction.
Ok.
> * By default, non-constant initialized variables will be placed in near
> memory.
Depends on the chip. m32c doesn't assume that.
> * By default, non-constant non-initialized variables will be placed in
> near memory.
Likewise.
> * New attribute "far" (to use external memory for non-constant data
> storage) will be added.
Ok, but for *any* data you want to force into far memory.
> * Non-constant non-initialized variables specified with the attribute
> "far" will be placed in a section ".fbss" (far memory).
Ok.
> * Non-constant initialized variables specified with the attribute "far"
> will be placed in a section ".fdata" (far memory).
Ok.
> * LDE/STE instructions will be used to access the non-constant variables
> specified with the attribute "far".
Ok.
> * MOV instructions will be used to access the constant variables
> specified with the attribute "near".
Ok.
> * Default linker script will be modified for placing the default section
> '.nbss', '.ndata' and '.nrodata' in near memory and '.fbss', '.fdata'
> and '.frodata' in far Memory.
Ok. Also, .rodata can be in far memory on m16c. For most R8C, .f*
should be put in near memory, because that's all it has.
> * Separate libraries will be used for R8C and M16C targets.
Ok.
> * As the libraries will be built without any attribute, all the constant
> data in library will be accessed using LDE instructions. Similarly,
> non-constant non-initialised and non-constant initialised data in
> library will be accessed using MOV instructions.
Ok, for m16c. For r8c, everything defaults to near(*), for m32c,
everything defaults to far, and the linker sorts it out.
(*) even the r8c/2d, which have far flash, have enough near flash to
handle .rodata, and near accesses are more optimal than far accesses
most of the time.
Re: m68k bootstrap problem
Roman Zippel wrote:
> Hi,
>
> On Fri, 22 Jun 2007, Kenneth Zadeck wrote:
>
>
>>> Index: gcc/gcc/reg-stack.c
>>> ===
>>> --- gcc.orig/gcc/reg-stack.c
>>> +++ gcc/gcc/reg-stack.c
>>> @@ -2316,6 +2316,12 @@ subst_stack_regs (rtx insn, stack regsta
>>>if (NOTE_P (insn) || INSN_DELETED_P (insn))
>>> return control_flow_insn_deleted;
>>>
>>> + if (SIBLING_CALL_P (insn))
>>> +{
>>> + CLEAR_HARD_REG_SET (regstack->reg_set);
>>> + return control_flow_insn_deleted;
>>> +}
>>> +
>>>/* If this a noreturn call, we can't insert pop insns after it.
>>> Instead, reset the stack state to empty. */
>>>if (CALL_P (insn)
>>>
>>>
>> so how are you coming with the 68k?
>>
>
> I started the bootstrap with my change and it works fine now, the tests
> are still running but so far there is no dataflow related problem. :)
> I'll drop my patch, the live information for an abnormal edge isn't really
> important anymore assuming the right thing is done for last call insn in
> that block. reg-stack could make use of it, but I'll leave that to someone
> else... :-)
>
> bye, Roman
>
you should run the regstack part past honza. Do not just let it drop if
you think it needs it.
gcc-4.3-20070622 is now available
Snapshot gcc-4.3-20070622 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070622/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 125959 You'll find: gcc-4.3-20070622.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070622.tar.bz2 C front end and core compiler gcc-ada-4.3-20070622.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070622.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070622.tar.bz2 C++ front end and runtime gcc-java-4.3-20070622.tar.bz2 Java front end and runtime gcc-objc-4.3-20070622.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070622.tar.bz2The GCC testsuite Diffs from 4.3-20070615 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
