Re: VAX backend status

[Paolo Bonzini]

I've noticed a few things in doing the above.  GCC 4.x doesn't seems to
do CSE on addresses.  Because the VAX binutils doesn't support non-local
symbols with a non-zero addend in the GOT, PIC will do a define_expand
so that (const (plus (symbol_ref) (const_int))) will be split into
separate instructions.  However, gcc doesn't seem to be able to take
advantage of that.  For instance, gcc emits:


File a PR, CC me and ping me when your patches are in.  I
can take a look and see whether it's the responsibility of
the VAX backend to provide more correct costs, or whether
fwprop could do something it's not doing.

Paolo

Re: Proposal: changing representation of memory references

[Zdenek Dvorak]

Hello,

> >Remarks:
> >-- it would be guaranteed that the indices of each memory reference are
> >   independent, i.e., that &ref[idx1][idx2] == &ref[idx1'][idx2'] only
> >   if idx1 == idx1' and idx2 = idx2'; this is important for dependency
> >   analysis (and for this reason we also need to remember the list of
> >   indices, rather than trying to reconstruct them from the address).
> 
> I didn't completely think through this,
> but how would this property help in the presence of array flattening ?
> e.g. suppose two adjacent loops, both two-nest-deep,
> and only one of them is flattened, then
> one loop will have one dimensional access (hence will have only one index)
> vs the other loop will have two dimensional.
> In other words, &ref[idx1] == &ref[idx1'][idx2'] can happen.

this cannot happen.  Suppose you have a declaration

int ref[100][100];

Then the first reference would be represented as
tmp = (int (*)[1])) &ref;
tmp[idx1]

It cannot have ref as its base.

Similarly, if one wanted to implement the reverse transformation,
recovering multidimensional arrays from the flat representation,
he would have to transform

int a[1];
for (i = 0; i < 100; i++)
  for (j =  0; j < 100; j++)
a[100 * i + j] = ...

to

tmp = (int (*)[100][100]) &a;
for (i = 0; i < 100; i++)
  for (j =  0; j < 100; j++)
ref with base: tmp, indices: (i,j) = ...

> Another question is, how would the representation look
> for more complicated address calculations
> e.g. a closed hashtable access like:
> 
> table[hash_value % hash_size]
> 
> and would it help in such cases ?

I am not quite sure what you ask for here; this would just be
represented as

idx = hash_value % hash_size;

and reference with base: table, indices: (idx)

Zdenek

Re: Proposal: changing representation of memory references

[Richard Guenther]

On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:

Hello,

> >> >-- flags
> >> >
> >> >for each index, we remeber
> >> >-- lower and upper bound
> >> >-- step
> >> >-- value of the index
> >>
> >> This seems a lot, however, since most of it can be derived from the
> >> types, why are we also keeping it in the references.
> >
> >The lower bound and step may be SSA_NAMEs, see the current ARRAY_REF,
> >and as such, they need to be stored somewhere in IR (not just in type).
> >
> >> That is, unless we could share most of the  index struct (upper,
> >> lower, step)  among expressions that access them (IE make index be
> >> immutable, and require unsharing and resharing if you want to modify
> >> the expression).
> >
> >That appears a bit dangerous to me, I would rather avoid such tricks.
>
> Like Richard, I have doubts you are not going to increase memory if
> you store *this* much in every single memory access.

for structured accesses (ARRAY_REFs etc.) we now need much more memory --
4 pointers, plus overhead of the common tree fields.  My proposal will
save some memory here.


I can dig out a patch that removes the two pointers that are amost
always NULL.  But it didn't make a whole lot of a difference.

Richard.

Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

[Jesper de Jong]

I successfully build gcc-4.1.2 on Cygwin running on Windows XP
Professional with SP2.

Output from running /home/jesper/gcc-4.1.2/config.guess:
   i686-pc-cygwin

Output of 'gcc -v':
   Using built-in specs.
   Target: i686-pc-cygwin
   Configured with: /home/jesper/gcc-4.1.2/configure
--enable-threads=win32 --with-cpu=i686 --with-arch=i686
--with-tune=i686 --enable-languages=c,c++
   Thread model: win32
   gcc version 4.1.2

Languages: C, C++

Here are my notes about the process:

Followed the instructions at: http://gcc.gnu.org/install/index.html

Check prerequisites (http://gcc.gnu.org/install/prerequisites.html):
   gzip version 1.2.4  OK, I have 1.3.9
   bzip2 version 1.0.2 OK, I have 1.0.3
   GNU make version 3.79.1 OK, I have 3.81
   GNU tar version 1.14OK, I have 1.16.1
   GNU Multiple Precision Library (GMP) version 4.1Not yet
installed. Run Cygwin setup and get version 4.2.1-1 (category Libs)
   MPFR Library version 2.2.1  Not yet
installed. Run Cygwin setup and get version 2.2.1-1 (category Libs)

Download (http://gcc.gnu.org/install/download.html):
   I am only interested in the C and C++ compiler, so I download the
core and g++ packages (not the full distribution):
gcc-core-4.1.2.tar.bz2, gcc-g++-4.1.2.tar.bz2
   Unzip and untar these (using 7-Zip) into /home/jesper (which maps
to C:\cygwin\home\jesper)

Configuration (http://gcc.gnu.org/install/configure.html):
   cd /home/jesper
   mkdir gccobj
   cd gccobj
   /home/jesper/gcc-4.1.2/configure --enable-threads=win32
--with-cpu=i686 --with-arch=i686 --with-tune=i686
--enable-languages=c,c++

   The configuration seems to complain that the right version of GMP
is not installed, even though I installed it (see above).
   I ignore the message.

Building (http://gcc.gnu.org/install/build.html):
   make

Final install (http://gcc.gnu.org/install/finalinstall.html):
   make install


Jesper de Jong
The Netherlands

Re: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

[Brian Dessent]

Jesper de Jong wrote:

> /home/jesper/gcc-4.1.2/configure --enable-threads=win32

Where do people keep getting this idea that Cygwin uses win32 threads? 
It doesn't, and you've most likely built a compiler that is subtly
broken in some way.  Cygwin uses pthreads, this should be
--enable-threads=posix.

Brian

Request for Bugzilla-only permissions

[Eric Weddington]

Hi,

Currently, and in the past I have been involved in the open source AVR
toolchain, mostly with other tools such as avr-libc
, and in building a popular
distribution of the tools which include GNU Binutils and GCC. I have been
keeping track of AVR-specific bugs (and bugs that may remotely affect the
AVR port) with a list on the avr-libc project site on Savannah:


My goal is to get more involved in Binutils, GCC, and possibly GDB, for the
AVR port, to help where I can. My FSF paperwork is in process on my
company's side but it may take a while. In the meantime I would like to
request Bugzilla-only permissions so I can at least help categorize the AVR
specific bugs.

All I am interested in is to be able to mark these bugs whether they have
been confirmed, or fixed, set the Keywords list, set the Known-to-work and
Known-to-fail lists, and in general just categorizing the latest state of
AVR bugs. Part of the reason for my request is some frustration in how long
it can take for other developers with permissions to come by and set these
fields after comments have been made on the bugs. Instead of being
frustrated, I'd much rather be able to help where I can. Besides, it will be
much easier to keep track of the state of the AVR port if these bugs are
better categorized as new information comes in. Also to that end, I'm trying
to do more to confirm the AVR bugs in my list.

Please note that I am *only* interested in bugs that affect, or may affect,
the AVR port at this time. I have no desire to mess around with bugs that
involve other areas.

Thanks for your time,
Eric Weddington 

Re: Proposal: changing representation of memory references

[Daniel Berlin]

On 4/4/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:

Hello,

> >> >> That is, unless we could share most of the  index struct (upper,
> >> >> lower, step)  among expressions that access them (IE make index be
> >> >> immutable, and require unsharing and resharing if you want to modify
> >> >> the expression).
> >> >
> >> >That appears a bit dangerous to me, I would rather avoid such tricks.
> >>
> >> Like Richard, I have doubts you are not going to increase memory if
> >> you store *this* much in every single memory access.
> >
> >for structured accesses (ARRAY_REFs etc.) we now need much more memory --
> >4 pointers, plus overhead of the common tree fields.  My proposal will
> >save some memory here.
>
> I'm not sure how, since you have more than 4 pointers worth of info in:
>
> -- base of the reference -> pointer
> -- constant offset -> HOST_WIDE_INT
> -- vector of indices -> embedded vec
> -- type of the accessed location -> Pointer
> -- original tree of the memory reference (or another summary of the
> structure of the access, for aliasing purposes) -> pointer
> -- flags -> No idea
>
> for each index, we remeber
> -- lower and upper bound -> pointers
> -- step -> pointer
> -- value of the index -> pointer
>
> What have i misunderstood?

consider a[i][j], on 32 bit machine:

Currently, this is two ARRAY_REFS, 40 bytes each, for total of 80 bytes.
With my proposal, this would be 24 bytes (the items contained in the
base of tree_exp: tree_common, including type+flags; locus, and block),
base, offset, summary, vector (16 bytes), in the vector size and bound
(8 bytes), plus 2 indices (16 bytes each), for total of 80 bytes.

I.e., we get the same memory consumption for references with at least
two levels.  For each other index or component ref, the proposed
representation saves 40 - 16 = 24 bytes.


Thanks for explaining it.
I really appreciate it.
As I said, my only real concern was memory usage.  I really want and
like the idea of a single unified memory reference :)

Re: Request for Bugzilla-only permissions

[Daniel Berlin]

On 4/5/07, Eric Weddington <[EMAIL PROTECTED]> wrote:

Hi,


My goal is to get more involved in Binutils, GCC, and possibly GDB, for the
AVR port, to help where I can. My FSF paperwork is in process on my
company's side but it may take a while. In the meantime I would like to
request Bugzilla-only permissions so I can at least help categorize the AVR
specific bugs.



Please note that I am *only* interested in bugs that affect, or may affect,
the AVR port at this time. I have no desire to mess around with bugs that
involve other areas.


If nobody objects or points out to me something in our contribution
guidelines about bugzilla write access requirements, i'll give you
access on monday.

Just email me your bugzilla username.



Thanks for your time,
Eric Weddington

RE: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

[Dave Korn]

On 05 April 2007 13:52, Brian Dessent wrote:

> Jesper de Jong wrote:
> 
>> /home/jesper/gcc-4.1.2/configure --enable-threads=win32
> 
> Where do people keep getting this idea that Cygwin uses win32 threads?
> It doesn't, and you've most likely built a compiler that is subtly
> broken in some way.  Cygwin uses pthreads, this should be
> --enable-threads=posix.


  Actually, unless you have a /very/ good reason, you simply shouldn't specify
it at all.  The build system will DTRT.  (As a general rule, the less options
you pass to configure, the less likely you are to make a wrong choice!)


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Variable scope debug info

[Rob Quill]

Hi,

I wrote an email about this a while ago, but it was rather consice and
didn't explain the problem well.

My problem is thus: When using GDB do debug the follow bit of code:

int i = 0;
int j = 2;
int k = 3;

If I set a breakpoint at the 3rd line, before int k = 3; has been
executed, and check if k is in scope, I find that it is, when, of
course, it shouldn't be. I emailed the GDB mailing list about this and
was informed that the problem arose because GCC does not emmit and GDB
cannot handle the DW_AT_start_scope attribute (DWARF 3 standard, page
61, item 11). Normally this is not a problem, but in my particular
case, the checking of variable values is automated, with decisions
being made on the value of those variables, so a variable being in
scope and having an incorrect value will result in a incorrect
decision being made.

I have be warned that attempting to do this (from GDB's perspective)
is not likely to be easy, and will more than likely bring forth new
problems, but doing it would greatly help the correctness of what I am
trying to do, and unless anyone has any objections, I think there is
no reason not to make something meet the specification.

So, assuming no-one has any objections, my question is, how do I go
about trying to do it in GCC? What should I look at and where should I
look?

Thanks for your help.

Rob

Re: bad edge created in CFG ?

[Sunzir Deepur]

Hi,

On 3/14/07, Seongbae Park <[EMAIL PROTECTED]> wrote:

On 3/14/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote:
> I have used -da and -dv to produce vcg files of the CFG of this simple 
program:
>
> int main(int argc, char**argv)
> {
> if(argc)
> printf("positive\n");
> else
> printf("zero\n");
>
> return 0;
> }
>
> I have expected to get a CFG as follows:
>
>  ---
>  | BB 0 |
>  ---
>   /  \
>--- ---
>| BB 1 |  | BB 2 |
>--- ---
>   \  /
>  ---
>  | END |
>  ---
>
> But instead, I was surprised to get this CFG:
>
>  ---
>  | BB 0 |
>  ---
>   /  \
>--- ---
>| BB 1 |  > | BB 2 |
>--- ---
>   \  /
>  ---
>  | END |
>  ---
>
> as if one case of the "if" can lead to the other !
>

I don't know what kind of vcg viewer/converter you're using,
but set it to ignore class 3 edges - you'll get what you expected.


I have used an evaluation copy of aiSee viewer (can i use graphviz for
displaying gcc's vcg files ?)

Can you please explain me why has this edge been created ?
What are class 3 edges ? can I prevent them from being created ?

Thank You Very Very Much !!
Sunzir.



--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";

Re: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

[Jesper de Jong]

Hello Brian,

Maybe because the configuration instructions:
http://gcc.gnu.org/install/configure.html
suggest that there is a choice and if you don't know better you will
think "I'm using Windows so I can use win32 threads".

Jesper

2007/4/5, Brian Dessent <[EMAIL PROTECTED]>:

Jesper de Jong wrote:

> /home/jesper/gcc-4.1.2/configure --enable-threads=win32

Where do people keep getting this idea that Cygwin uses win32 threads?
It doesn't, and you've most likely built a compiler that is subtly
broken in some way.  Cygwin uses pthreads, this should be
--enable-threads=posix.

Brian





--
Jesper de Jong
[EMAIL PROTECTED]

Re: Variable scope debug info

[Ian Lance Taylor]

"Rob Quill" <[EMAIL PROTECTED]> writes:

> My problem is thus: When using GDB do debug the follow bit of code:
> 
> int i = 0;
> int j = 2;
> int k = 3;
> 
> If I set a breakpoint at the 3rd line, before int k = 3; has been
> executed, and check if k is in scope, I find that it is, when, of
> course, it shouldn't be. I emailed the GDB mailing list about this and
> was informed that the problem arose because GCC does not emmit and GDB
> cannot handle the DW_AT_start_scope attribute (DWARF 3 standard, page
> 61, item 11). Normally this is not a problem, but in my particular
> case, the checking of variable values is automated, with decisions
> being made on the value of those variables, so a variable being in
> scope and having an incorrect value will result in a incorrect
> decision being made.

...

> So, assuming no-one has any objections, my question is, how do I go
> about trying to do it in GCC? What should I look at and where should I
> look?

Look in gcc/dwarf2out.c at the handling of VAR_DECL.  Good luck.

Ian

Re: Variable scope debug info

[Joe Buck]

On Thu, Apr 05, 2007 at 02:37:06PM +0100, Rob Quill wrote:
> My problem is thus: When using GDB do debug the follow bit of code:
> 
> int i = 0;
> int j = 2;
> int k = 3;
> 
> If I set a breakpoint at the 3rd line, before int k = 3; has been
> executed, and check if k is in scope, I find that it is, when, of
> course, it shouldn't be. I emailed the GDB mailing list about this and
> was informed that the problem arose because GCC does not emmit and GDB
> cannot handle the DW_AT_start_scope attribute (DWARF 3 standard, page
> 61, item 11).

If adding scope attributes every time more than one variable is declared
adds to the already immense bulk of C++ debugging information, I'd
prefer to live with the bug myself.

Re: Variable scope debug info

[Rob Quill]

On 05/04/07, Joe Buck <[EMAIL PROTECTED]> wrote:

On Thu, Apr 05, 2007 at 02:37:06PM +0100, Rob Quill wrote:
> My problem is thus: When using GDB do debug the follow bit of code:
>
> int i = 0;
> int j = 2;
> int k = 3;
>
> If I set a breakpoint at the 3rd line, before int k = 3; has been
> executed, and check if k is in scope, I find that it is, when, of
> course, it shouldn't be. I emailed the GDB mailing list about this and
> was informed that the problem arose because GCC does not emmit and GDB
> cannot handle the DW_AT_start_scope attribute (DWARF 3 standard, page
> 61, item 11).

If adding scope attributes every time more than one variable is declared
adds to the already immense bulk of C++ debugging information, I'd
prefer to live with the bug myself.


Out of interest, why? I haven't looked into this properly yet, so I
don't know what problems it might cause. Will having this much more
debug info significantly slow down GCC/GDB? Will it have other
problems?

Rob

Re: Variable scope debug info

[Joe Buck]

I wrote:
> >If adding scope attributes every time more than one variable is declared
> >adds to the already immense bulk of C++ debugging information, I'd
> >prefer to live with the bug myself.

On Thu, Apr 05, 2007 at 05:36:57PM +0100, Rob Quill wrote:
> Out of interest, why? I haven't looked into this properly yet, so I
> don't know what problems it might cause. Will having this much more
> debug info significantly slow down GCC/GDB? Will it have other
> problems?

The executables I am currently working on are 223 Mb and 341 Mb with -g,
and these are smaller than some others I have to deal with.  The
test/debug/recompile loop I spend much of my life in lately is
dominated by link time.  The link time is strongly affected by
the size of the debug information.  So it's not the cost of the
disk space, that's relatively cheap; it's the time increase
caused by reading, writing, and processing more data.

Now, it might turn out that adding additional dwarf records for
every single declaration won't significantly increase the size
of the debug information.  But it is a consideration.

Re: Variable scope debug info

[Brian Ellis]

Now if there were actual function calls in the initialization, and no records 
were emitted, I would consider that to be a problem (haven't tested this at the 
moment though), however, static initializers like that could easily be skipped 
as a feature in the interest of saving space.

Example :
int i = 0;
int j = 2;
int n = CalculateSomething( j, &i );
int k = 3;

I would expect debug records for the initialization of 'n' to be emitted and a 
break point to properly work on that line... all others I could completely care 
less for. Heck, if the scope for k (being a primitive type that is initialized 
with a compile-time constant value) were started before n, i wouldn't even 
consider that to be a bug... I would consider it a marvel of intelligence in 
the compiler.

- Brian

- Original Message 
From: Joe Buck <[EMAIL PROTECTED]>
To: Rob Quill <[EMAIL PROTECTED]>
Cc: GCC Development 
Sent: Thursday, April 5, 2007 12:32:04 PM
Subject: Re: Variable scope debug info

On Thu, Apr 05, 2007 at 02:37:06PM +0100, Rob Quill wrote:
> My problem is thus: When using GDB do debug the follow bit of code:
> 
> int i = 0;
> int j = 2;
> int k = 3;
> 
> If I set a breakpoint at the 3rd line, before int k = 3; has been
> executed, and check if k is in scope, I find that it is, when, of
> course, it shouldn't be. I emailed the GDB mailing list about this and
> was informed that the problem arose because GCC does not emmit and GDB
> cannot handle the DW_AT_start_scope attribute (DWARF 3 standard, page
> 61, item 11).

If adding scope attributes every time more than one variable is declared
adds to the already immense bulk of C++ debugging information, I'd
prefer to live with the bug myself.






 

Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

Re: Variable scope debug info

[Joe Buck]

On Thu, Apr 05, 2007 at 10:21:28AM -0700, Brian Ellis wrote:

> Now if there were actual function calls in the initialization, and no
> records were emitted, I would consider that to be a problem (haven't
> tested this at the moment though), however, static initializers like
> that could easily be skipped as a feature in the interest of saving
> space.

> Example :
> int i = 0;
> int j = 2;
> int n = CalculateSomething( j, &i );
> int k = 3;

> I would expect debug records for the initialization of 'n' to be emitted
> and a break point to properly work on that line...

and, in fact, breakpoints set on that line work as expected.

Re: Variable scope debug info

[Mike Stump]

On Apr 5, 2007, at 9:46 AM, Joe Buck wrote:
The test/debug/recompile loop I spend much of my life in lately is  
dominated by link time.


We found that omitting the debug information from the link step  
solves this issue.

RE: Bootstrap is broken on i[345]86-linux

[Meissner, Michael]

> -Original Message-
> From: FX Coudert [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 03, 2007 6:01 PM
> To: gcc@gcc.gnu.org
> Cc: Meissner, Michael; [EMAIL PROTECTED]
> Subject: Bootstrap is broken on i[345]86-linux
> 
> Bootstrap has been broken since 2007-03-25 on i[345]86-linux. This is
a
> decimal float issue reported as PR31344, and is due to a decimal float
> patch, probably the following:
> 
> 2007-03-23  Michael Meissner  <[EMAIL PROTECTED]>
> H.J. Lu  <[EMAIL PROTECTED]>
> 
> I've asked a few times already, but nothing seems to be done: can this
be
> fixed? A simple workaround is to disable decimal float for
i[345]86-linux,
> and it would be nice if people who commit patches acted as if they
felt
> responsible for the consequences of their commits.
> 
> FX

I'm starting to look into it now.

Re: Variable scope debug info

[Daniel Jacobowitz]

On Thu, Apr 05, 2007 at 09:46:18AM -0700, Joe Buck wrote:
> Now, it might turn out that adding additional dwarf records for
> every single declaration won't significantly increase the size
> of the debug information.  But it is a consideration.

FWIW, I would expect that it would not make a significant difference.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

[Aaron W. LaFramboise]

Brian Dessent wrote:

Jesper de Jong wrote:


/home/jesper/gcc-4.1.2/configure --enable-threads=win32


Where do people keep getting this idea that Cygwin uses win32 threads? 
It doesn't, and you've most likely built a compiler that is subtly

broken in some way.  Cygwin uses pthreads, this should be


Jesper,

If you have the time and inclination, you might consider running the 
testsuite with --enable-threads and with --enable-threads=win32, and 
seeing if there's any difference, and report back here with the results.


I don't really see any compelling reason that win32 threads shouldn't 
work on Cygwin.  As far as I know, nothing about this choice is 
ultimately exposed to the user.  In fact, Win32 threads are quite likely 
to yield superior performance anywhere where it matters.


One place it might cause problems is if it enabled any of that mingwm or 
whatever stuff.

Re: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

[Brian Dessent]

"Aaron W. LaFramboise" wrote:

> I don't really see any compelling reason that win32 threads shouldn't
> work on Cygwin.  As far as I know, nothing about this choice is
> ultimately exposed to the user.  In fact, Win32 threads are quite likely
> to yield superior performance anywhere where it matters.

There is a very compelling reason.  If you go creating threads behind
Cygwin's back by calling the Win32 API directly, you will quickly get
very wrong results as you try to use other features of Cygwin.  In order
to correctly emulate a posix API under Windows, Cygwin has to handle all
creation and deletion of resources, including threads, and the
corresponding bookkeeping to keep track of them.

The only way this would ever work is if you didn't use any features of
Cygwin (especially any pthreads functions), and stuck to the Win32 API
entirely.  But then, that would be completely missing the point of
Cygwin, which is to provide the posix API.  If you want to use native
Win32 threads, use MinGW.  --enable-threads=win32 is the correct choice
for MinGW.

Brian

Has anyone ever tried to implement lazy strength reduction for GCC?

[Steven Bosscher]

Hello,

One of the suggestions Jeff made wrt. simplifying regmove, was that
some parts of it can be implemented more elegantly with the lazy
strength reduction algorithm, which is an extension of PRE as
implemented in GCC's gcse.c.

Has anyone ever tried implementing this for GCC?  Bonus if there's a
finished or unfinished patch that I could look at ;-)

Thanks,
Gr.

Steven