headers
kernel coder | 1 Jul 2006 08:32
Picon

explaination of some gcc functions

hi,
     I'm trying to understand the backend code of gcc for MIPS
architecture.I'm having some trouble while understanding following
functions.

1:  push_topmost_sequence();
2: emit_insn_after(seq,get_insns());
3: pop_topmost_sequence();
4: emit_insn_before

Would you please explain what's the role of each function.
Permalink | Reply | 3 comments |
headers
Eric Christopher | 1 Jul 2006 09:14
Picon
Favicon

Re: explaination of some gcc functions

kernel coder wrote:
> hi,
>     I'm trying to understand the backend code of gcc for MIPS
> architecture.I'm having some trouble while understanding following
> functions.

I think most of these are obvious, what problems in specific are you 
having with them?

-eric
Permalink | Reply | 2 comments |
headers
kernel coder | 1 Jul 2006 09:54
Picon

Re: explaination of some gcc functions

I'm having trouble in understanding the term sequnce in an insn
chain.get_insns() actually returns the current instruction.What does
the term "sequence" mean,as the name suggests it must be a sequence of
instructions ,but in an instruction chain,a single element will be an
instruction ,then what is meant by sequence.

When push_topmost_sequence is called ,it should push a sequence of
instructions ,but an element of insn chain is a single
instruction,then which sequence will be pushed.

Suppose following is a sequnce of instructions.

1)    entry_insns = get_insns ();
2)     push_topmost_sequence ();
3)      emit_insn_after (entry_insns, get_insns ());
4)      pop_topmost_sequence ();

In 1) current insn is saved in entry_insns. what is happening in In
2).Is sequence differnet from insn in an insn chain ,any example will
be helpful.

In 3) instruction  the entry_insns is being put after the instruction
obtained through get_insns() .But does get_insns() also increaments
the current instruction pointer.If not then shouldn't the same
instruction be emitted in 3).

Now again which sequnce is being  poped out in 4).

On 7/1/06, Eric Christopher <echristo <at> apple.com> wrote:
> kernel coder wrote:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gerald Pfeifer | 1 Jul 2006 15:42

Re: What happend to bootstrap-lean? (was: What happened to bubblestrap?)

Hi Paolo,

since we are approaching the GCC 4.2 release, I thought I'd point 
out the question of bootstrap-lean again, which is still documented
and which I found rather useful in some settings.

On Sat, 17 Dec 2005, Gerald Pfeifer wrote:
> On Fri, 16 Dec 2005, Paolo Bonzini wrote:
>> Yes.  "make bubblestrap" is now called simply "make".
> Okay, how is "make bootstrap-lean" called these days? ;-)
> 
> In fact, bootstrap-lean is still documented in install.texi and 
> makefile.texi, but it no longer seems to be present in the Makefile
> machinery.  Could we get this back?

Also, would you mind adding some notes to gcc-4.2/changes.html, as
far as changes are user visible?

Thanks,
Gerald
Permalink | Reply | 15 comments |
headers
Christopher Faylor | 1 Jul 2006 17:56

Re: Notes of the libgcc-math BOF at the summit.

On Fri, Jun 30, 2006 at 02:57:19PM +0200, Richard Guenther wrote:
>Issues of providing both standard conforming and target optimized
>math runtimes for GCC were discussed.

Thanks for posting this.  Since I wasn't able to attend the summit this
year, I really appreciate seeing summaries like this.

cgf
Permalink | Reply | 0 comments |
headers
Elmar Krieger | 1 Jul 2006 20:49
Picon

void* <-> char* aliasing rule, C standard or glitch?

Hi GCClers,

I searched hard, but couldn't determine conclusively if the C standard 
allows to alias a void* pointer with a char* pointer.

If that's not undefined behavior, then the following may be a glitch in 
GCC 4.1.0 when compiled with -O2.

Here's the ugly minimal piece of code:

/* ASSUME pointer POINTS TO AN INTEGER THAT SPECIFIES THE INCREMENT
    ================================================================ */
int increment(int *pointer)
{ return(*pointer); }

/* INCREMENT A POINTER BY THE NUMBER OF BYTES POINTED TO
    ===================================================== */
void *incremented(void *pointer)
{ int inc=increment(pointer);
   *((char**)&pointer)+=inc;
   return(pointer); }

What goes wrong is that the function incremented() increments the 
pointer, but returns the original, non-incremented value.

Here's the assembly code:

Dump of assembler code for function incremented:
0x08051f80 <incremented+0>:     push   %ebp
0x08051f81 <incremented+1>:     mov    %esp,%ebp
(Continue reading)

Permalink | Reply | 2 comments |
headers
gccadmin | 1 Jul 2006 19:54
Picon
Favicon

gcc-4.2-20060701 is now available

Snapshot gcc-4.2-20060701 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060701/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 115116

You'll find:

gcc-4.2-20060701.tar.bz2              Complete GCC (includes all of below)

gcc-core-4.2-20060701.tar.bz2         C front end and core compiler

gcc-ada-4.2-20060701.tar.bz2          Ada front end and runtime

gcc-fortran-4.2-20060701.tar.bz2      Fortran front end and runtime

gcc-g++-4.2-20060701.tar.bz2          C++ front end and runtime

gcc-java-4.2-20060701.tar.bz2         Java front end and runtime

gcc-objc-4.2-20060701.tar.bz2         Objective-C front end and runtime

gcc-testsuite-4.2-20060701.tar.bz2    The GCC testsuite

Diffs from 4.2-20060624 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steven Bosscher | 1 Jul 2006 19:59
Picon

Re: void* <-> char* aliasing rule, C standard or glitch?

On 7/1/06, Elmar Krieger <elmar <at> cmbi.ru.nl> wrote:
> I searched hard, but couldn't determine conclusively if the C standard
> allows to alias a void* pointer with a char* pointer.

Search in the GCC documentation, under -fstrict-aliasing:

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#index-fstrict_002daliasing-542

Gr.
Steven
Permalink | Reply | 0 comments |
headers
Gary Funck | 1 Jul 2006 20:23

externs and thread local storage


Consider the following program made up of two separate files:

==> file1.c <==
extern int x;

int main() {
x = 5;
}

==> file2.c <==
int __thread x = 10;

This will compile, link, and run on the IA64, but will fail at link time on
AMD64:

% gcc file2.c file1.c
/usr/bin/ld: x: TLS definition in /tmp/ccmdUAs3.o section .tdata mismatches
non-TLS reference in /tmp/ccuSmPAa.o
/tmp/ccuSmPAa.o: could not read symbols: Bad value
collect2: ld returned 1 exit status

However if the initial extern were changed to:
  extern __thread int x;
it will also compile, link, and run on the AMD64.

To further complicate matters, if the program is rewritten into a single
file as follows:

int __thread x;
(Continue reading)

Permalink | Reply | 20 comments |
headers
Andrew Haley | 1 Jul 2006 20:52
Picon
Favicon

Re: void* <-> char* aliasing rule, C standard or glitch?

Elmar Krieger writes:
 > 
 > I searched hard, but couldn't determine conclusively if the C standard 
 > allows to alias a void* pointer with a char* pointer.
 > 
 > If that's not undefined behavior, then the following may be a glitch in 
 > GCC 4.1.0 when compiled with -O2.
 > 
 > Here's the ugly minimal piece of code:
 > 
 > /* ASSUME pointer POINTS TO AN INTEGER THAT SPECIFIES THE INCREMENT
 >     ================================================================ */
 > int increment(int *pointer)
 > { return(*pointer); }
 > 
 > /* INCREMENT A POINTER BY THE NUMBER OF BYTES POINTED TO
 >     ===================================================== */
 > void *incremented(void *pointer)
 > { int inc=increment(pointer);

 >    *((char**)&pointer)+=inc;

Not legal C.  Do

    pointer = (char*)pointer + inc;

Andrew.
Permalink | Reply | 0 comments |

Gmane