gcc bug question regarding error recovery

[Pjotr Kourzanov]

Dear gcc developers,

  While trying a code snippet structured as the following code suggests I've
encountered a gcc error recovery bug. Namely, the gcc (versions 4.0-4.3, as well
as 3.2) starts leaking memory (after reporting that a variable-sized object can
not be initialized) and never exists. Strange enough, 3.3 also leaks but still
can exit gracefully. gcc-3.4 and gcc-2.95 both work as expected on this
fragment:

int main() { 

 const int size=10; 

 struct foo { 

 int array[size]; 

 int* p; 

 };// f = { .p=0 }; 




 struct foo f = { .p = 0 }; 


}

  Note that putting size as a #define solves the problem, just as well as 
putting the array to be placed after the pointer.


  I know that initialization of variable-sized object is explicitly prohibited
by C99, but note that the size here is a constant, and that I am trying to 
initialize a struct containing this seemingly variable-sized array.


  I would like to know if its a known bug, and if possible I could file a proper
bug report if this helps...

  I am using Debian-packaged compilers.

Regards,

Pjotr Kourzanov

Re: Proper way to make a one-off multi-file testcase?

[Paul Koning]

> "Hans-Peter" == Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:

 Hans-Peter> On Wed, 30 Jan 2008, Ian Lance Taylor wrote:
 >> One issue here is that in some cases const and pure calls can get
 >> combined and eliminated even with attribute noinline (unless this
 >> changed recently).  So in addition to attribute noinline, putting
 >> an asm volatile ("") in the function can help make it non-pure and
 >> non-const.

 Hans-Peter> (The "volatile" is redundant; an asm without in/out
 Hans-Peter> operands is always volatile.)

That's what the docs say, but I've seen indications that this is not
actually how it works.  (At least not a couple of releases ago.)

 paul

Re: Results for 4.3.0 20080125 (experimental) (GCC) testsuite on i386-unknown-openbsd4.2

[Dongsheng Song]

NO.
If no "--disable-werror" option, bootstrap will fail. So I use a type
cast, no very care about the pointer type.

2008/2/1, Vincent Lefevre <[EMAIL PROTECTED]>:
> On 2008-01-31 11:59:32 +0800, Dongsheng Song wrote:
> > -   mpfr_inits2 (prec, m1, m2, NULL);
> > +   mpfr_inits2 (prec, m1, m2, (char *)NULL);
>
> Is there any reason to use (char *) instead of (void *)?
>
> Note that m1 and m2 are MPFR pointers (mpfr_ptr type, which is in
> the reality __mpfr_struct * but that's internal).
>
> --
> Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
>

Re: Proper way to make a one-off multi-file testcase?

[Hans-Peter Nilsson]

On Wed, 30 Jan 2008, Ian Lance Taylor wrote:
> One issue here is that in some cases const and pure calls can get
> combined and eliminated even with attribute noinline (unless this
> changed recently).  So in addition to attribute noinline, putting an
> asm volatile ("") in the function can help make it non-pure and
> non-const.

(The "volatile" is redundant; an asm without in/out operands is
always volatile.)

That method has consensus as the officially supported method to
prevent the apparent effect of inlining (cases that aren't
inlining, but where you can't tell the difference as a user,
such as const/pure-optimization).

What remains is to document it as such, so we don't have to
re-ask every few weeks.

brgds, H-P

Re: Results for 4.3.0 20080125 (experimental) (GCC) testsuite on i386-unknown-openbsd4.2

[Vincent Lefevre]

On 2008-01-31 11:59:32 +0800, Dongsheng Song wrote:
> -   mpfr_inits2 (prec, m1, m2, NULL);
> +   mpfr_inits2 (prec, m1, m2, (char *)NULL);

Is there any reason to use (char *) instead of (void *)?

Note that m1 and m2 are MPFR pointers (mpfr_ptr type, which is in
the reality __mpfr_struct * but that's internal).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

4.2 branch frozen

[Joseph S. Myers]

The GCC 4.2 branch is now frozen for the 4.2.3 release.  Do not make any 
more commits to this branch until the 4.2.3 release is announced (after 
which the branch will go back to normal release branch mode).

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: gcc bug question regarding error recovery

[Ian Lance Taylor]

Pjotr Kourzanov <[EMAIL PROTECTED]> writes:

> int main() { const int size=10; struct foo {
> int array[size]; int* p; };// f = { .p=0 };
> struct foo f = { .p = 0 }; }

With gcc mainline, compiled with checking, I get an ICE:

/home/iant/foo1.c: In function ‘main’:
/home/iant/foo1.c:3: error: variable-sized object may not be initialized
/home/iant/foo1.c:3: internal compiler error: tree check: expected integer_cst, 
have mult_expr in tree_int_cst_lt, at tree.c:4919
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Thanks for the report.

Ian

Adding extra instructions in the Ready List

[Balaji V. Iyer]

Hello Everyone,
I am currently working with GCC 4.0.2 (The OpenRISC port).

Is it possible to add extra instructions (for example, NOPS) into
the instruction ready list. Is it possible for me to do it in
TARGET_MACHINE_SCHED_REORDER2? I tried to just do the following
 
rtx new_insn = gen_nop();
Insert_Into_List(ready_list, new_insn);
 
return *n_ready;
 
But it is complaining sometime later in the scheduler that it is not
able to find the basic block info for the new_insn (the one I inserted).
Can someone please help me with this? Am I forgetting to set any extra
variable?
 
Any help is greatly appreciated!
 
Please feel free to ask me if you need additional clarification
 
Thanks,
 
Balaji V. Iyer.
 
 
-- 
 
Balaji V. Iyer
PhD Student, 
Center for Efficient, Scalable and Reliable Computing,
Department of Electrical and Computer Engineering,
North Carolina State University.

 
 
-- 
 
Balaji V. Iyer
PhD Student, 
Center for Efficient, Scalable and Reliable Computing,
Department of Electrical and Computer Engineering,
North Carolina State University.

Some 4.4 project musings

[Andrew MacLeod]

There are a few things that I'm considering working on for the 4.4 
release, and I figured I'd see what others thought.  Is anyone 
considering/doing similar or related work? 


I'll summarize each, and then go into more details.

1 - Pass cleanup.  There have been rumblings about this, but I haven't 
seen a lot of actual progress. We currently run 100's of passes all the 
time, and we don't really know how effective or necessary many of them 
are. We also don't know whether the cleanups they run are truly doing 
much.  It would be nice to do some actual analysis and do something with 
the results.


2 - Interface to the virtual operands. The virtual operand web provides 
what really amounts to low level detail of memory accesses. Every pass 
that cares about memory access ends up interpreting the data and dealing 
with the VOP web modification itself. This is in some ways analogous to 
every pass having to implement bsi_insert() itself.  It would be nice if 
there was one standard central interpreter of the data that knows how to 
view and modify the web.  Richi is working on an alias oracle of some 
sort, I'm not sure of its details so I don't know how far it delves into 
this sort of thing, or what approach it takes.


3 - SRA.  There appear to be some deficiencies in SRA, and also how it 
interacts with the MEMSSA partitioner. I found when looking at some 4.3 
bugs that its never as simple as looking at the base and offset, at 
least not consistently.  Most of it appears to be 
first-implementation-itis, the discovering of new issues as you go. 
Stepping back and reviewing the functional requirements and its 
interaction with the partitioner should be useful.


4 - SSA pressure reduction. I'm throwing this back on the table. I never 
quite got around to it before, and nothing has changed to resolve the 
issues. We freely create as much register pressure in the SSA optimizers 
as we want (as we should be able to).  The backend has doing nothing to 
address the issue and the RTL register allocator is simply swamped by 
the sheer quantity of live ranges sometimes.  Perhaps Vlad's RA will get 
in this release, and/or perhaps the need for this will be eliminated by 
something else, but it is something that may help code generation in the 
short term at least.


Those are the primary subjects, in no particular order. Now I'll delve a 
bit deeper into the details of whats involved for each one. 

If anyone is interested in any of these tasks, or has any 
questions/observations/criticisms, please let me know. (I know you will! 
:-)


I will also stick something up on the wiki in a bit with this 
information, and whatever other details come out from 
suggestions/discussions or further investigation.




Pass Cleanup
-

It would sure be nice to streamline our pass pipeline.  One could spend 
the rest of ones life doing this by hand. The 2 biggest problems would 
seem to be:

* we have no idea whether a pass actually does much
* and we have no idea whether it was actually useful

So I was thinking that maybe we could modify passes to report what they 
did. When CHECKING_ENABLED is on (or something like that), every pass 
reports what it did, possibly to the pass manager.


Initially I was thinking it might have something like:
   * number of statements changed
   * number of statements added
   * number of statements deleted
   * number of names added
   * number of names deleted

And then a report is issued for the compilation listing every pass that 
ran and a summary of this data for each occurrence.  Each of the TODO 
cleanups run by each pass should also have its data listed.


Then we could run the compiler over a whack of testcases, accumulate all 
these reports, and generate some data on which passes and cleanups are 
not doing very much and are candidates for closer inspection.


One could then turn off one or more of these passes, run again, and see 
whether there appeared to be much impact on the other passes.


A closer inspection may identify that perhaps the pass should be 
somewhere else in the pipeline, run only at -O3, completely eliminated, 
or modified in some way.  


There are also categories of optimizations:
 * optimization performers - The workhorses that actually do useful things.
 * optimization enablers - introduce situations which will enable a 
later optimizer.
 * cleanups - Those which remove crud or undo enabler work which was 
not profitable.


And these should probably be treated differently. Enablers tend to work 
in concert with optimizations and sometime also cleanups. You need to 
look at the data for them together to see if useful work was done. If 
the cleanup is usually undoing everything the enabler did, then the 
enabler isn't really enabling, its just chewing cycles :-) (or there is 
a flaw in the optimization, in any case, it all deserves a closer look 
if the group isn't accomplishing much)


It also possible that a pass should only be run on a specif

Re: Proper way to make a one-off multi-file testcase?

[Hans-Peter Nilsson]

On Fri, 1 Feb 2008, Paul Koning wrote:
> > "Hans-Peter" == Hans-Peter Nilsson <[EMAIL PROTECTED]> writes:
>  Hans-Peter> (The "volatile" is redundant; an asm without in/out
>  Hans-Peter> operands is always volatile.)
>
> That's what the docs say, but I've seen indications that this is not
> actually how it works.  (At least not a couple of releases ago.)

I'd like to see a bug-report.  I have seen indications that
this is a bug that has been fixed.

brgds, H-P

Re: Some 4.4 project musings

[Richard Guenther]

On Feb 1, 2008 9:55 PM, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
>
> There are a few things that I'm considering working on for the 4.4
> release, and I figured I'd see what others thought.  Is anyone
> considering/doing similar or related work?
>
> I'll summarize each, and then go into more details.

> Pass Cleanup
> -
>
> It would sure be nice to streamline our pass pipeline.  One could spend
> the rest of ones life doing this by hand. The 2 biggest problems would
> seem to be:
>  * we have no idea whether a pass actually does much
>  * and we have no idea whether it was actually useful

I would add

 * re-ordering passes makes the compiler break

so we need to uncover existing bugs by doing some re-ordering experiments.

What I'd like to do very early in 4.4 is

 - run those cleanups that are run after first may_alias pass (mainly
ccp, copyprop
   and forwprop) right after the final inlining, but before the first
may_alias pass.
   This will reduce the amount of pointers and addressable vars we
need to process
in may_alias (which helps my goal of reducing the number of VOPs,
see also below)

 - go into-SSA even for -O0, mainly to
* run TER at -O0, improving initial rtl code quality
* remove paths in the middle-end that are double, like SSA inlining and
   non-SSA inlining, TER/non-TER expansion

 - do gimplification unit-at-a-time to allow IL lowering at a point
the TU is complete
   (this will be the last chance to call back to the frontends)

 - output (some) debug information early, mainly everything that is FE
dependent such
   as types and decls;  this enables us to lower datastructures of
decls and types to
   a middle-end representation (no more trees, wh)


> Interface to Virtual Operands
> -
>
> I'd like to do a survey of all the optimizations which use virtual
> operands to see how they use it and how they manipulate it. From that,
> we can extrapolate the kinds of questions that are asked and the kinds
> of manipulations that are performed. In particular look for slight
> variations in the interpretation or manipulation of the VOP data.
>
> Until that survey is done, its hard to predict what the interface
> routines would be. There are certainly a base set such as
>  * can a load/store to B be inserted before/after this stmt
>  * can a load/store from B be moved from stmt1 to stmt2 safely
>  * if not, which stmt(s) are the blockers
>  * insert a store to B.
>  * etc, etc.
>
> The survey would help fill out this list and identify commonly done
> tasks and needs. We do enough stuff now that it would make a pretty good
> representational data set I think.
>
> I expect some passes hold a modified state within the pass which isn't
> reflected in the VOP web. The interpreter could maybe hold an internal
> modified state as well where the interface allows a pass to say 'I'm
> pretending to insert this stmt , and that stmt is fake-deleted'. It
> would then allow the queries to reflect the situation based on these
> modifications.  This state could be a state stack if need be for
> unwinding changes.  This would prevent optimizations from having to take
> care of all this crap themselves, and simplify maintenance and future
> coding.
>
> That might turn out to be quite difficult, its hard to say without the
> initial survey of what and how things are done.  We certainly have
> enough passes using the information now that we can get a feel for what
> common ground there is for interpreting the VOP web.
>
> In thinking about a pressure reduction pass for instance, it would be
> much simpler to write it if these facilities were in place as general
> routines, even if it were just the query routines.  I'm assuming Richi's
> oracle would address some of this?

My priority here is to get rid of SFTs and all the complexity (in memory
and compile-time) they cause.  Passes that do optimizations on stores/loads
will be enhanced to cope with very imprecise virtual operand chains,
thus mainly use it for efficient walking of interesting stmts.  FRE is ready
(there are some general issues with SCCVN and I didn't yet look at PRE),
we also have a patch from Zdenek for load/store motion in loops.


I share the feelings about SRA and I would add that we need a replacement
implementation for DSE.

Richard.

Re: Contributing to cross-compiling

[Robert Schwebel]

On Thu, Jan 31, 2008 at 12:46:41PM +, Martin Guy wrote:
> 2008/1/31, Manuel López-Ibáñez <[EMAIL PROTECTED]>:
> > Nonetheless, if someone decided to go through the hassle of collecting
> > tutorials and hints for various cross-compiling configurations in the
> > wiki, I think many users will appreciate it. It is still considered by
> > many to be a "dark art"[*].
>
> The crosstool project http://kegel.com/crosstool is a humungous shell
> script with configuration files that has collected a lot of the
> "community wisdom" over the years about the necessary runes to build
> cross-compilers for different scenarios and with different
> target-cpu/gcc/glibc/OS combinations.
>
> There is also a menu-driven spin-off project, crosstool-ng, which is
> less mature but embodies the same set of knowledge.

And there is OSELAS.Toolchain:

http://www.pengutronix.de/oselas/toolchain/download/

Mature for the supported compilers, patches are welcome for anything
else :-)

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
 Hannoversche Str. 2, 31134 Hildesheim, Germany
   Phone: +49-5121-206917-0 |  Fax: +49-5121-206917-9

gcc-4.3-20080201 is now available

[gccadmin]

Snapshot gcc-4.3-20080201 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080201/
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 132053

You'll find:

gcc-4.3-20080201.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080201.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080201.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080201.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080201.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080201.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080201.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080201.tar.bz2The GCC testsuite

Diffs from 4.3-20080125 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.

Re: Some 4.4 project musings

[Manuel López-Ibáñez]

On 01/02/2008, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On Feb 1, 2008 9:55 PM, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> >
> > There are a few things that I'm considering working on for the 4.4
> > release, and I figured I'd see what others thought.  Is anyone
> > considering/doing similar or related work?
> >
> > I'll summarize each, and then go into more details.
>
> > Pass Cleanup
> > -
> >
> > It would sure be nice to streamline our pass pipeline.  One could spend
> > the rest of ones life doing this by hand. The 2 biggest problems would
> > seem to be:
> >  * we have no idea whether a pass actually does much
> >  * and we have no idea whether it was actually useful
>
> I would add
>
>  * re-ordering passes makes the compiler break
>

Re-ordering of passes would be easier if passes destroyed properties
when they invalidate it, and the pass manager invoked the necessary
TODO_functions to re-create them when a pass asks for a missing
property.

For example if alias information has gone stale because of some pass,
then that pass destroys PROP_alias. Now a later pass requires alias
information to do their magic but PROP_alias is missing, so they
invoke compute_may_aliases to restore PROP_alias.

This was discussed previously here:
http://gcc.gnu.org/ml/gcc/2007-09/msg00512.html

I have been thinking about this because I needed something similar to
enable SSA at -O0 so we can run -Wuninitialized.

Cheers,

Manuel.

4.2 branch open again

[Joseph S. Myers]

The GCC 4.2 branch is now open for commits again under normal release 
branch rules.  The official 4.2.3 release announcement will go out later 
(probably on Sunday) after mirrors have had time to update.

The next 4.2 release is likely to be in about two months' time, with 
releases continuing at two month intervals as long as some RM wishes to do 
them.  Hopefully 4.3.0 will be ready well before 4.2.4.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

[tuples] If you need to re-enable -O2

[Diego Novillo]

I forgot to add in my earlier patch that if you are working on
converting a pass and need to enable -O2 in your local tree, you can
apply this reversal patch to opts.c:

Index: opts.c
===
--- opts.c  (revision 132051)
+++ opts.c  (working copy)
@@ -775,16 +775,6 @@ decode_options (unsigned int argc, const
}
 }

-  /* FIXME tuples.  Force optimization level to 0 until alias analysis
- and complex lowering at O1+ is fully enabled.  */
-  if (flag_gimple_conversion == 0)
-{
-  optimize = 0;
-  optimize_size = 0;
-}
-  else
-gimple_unreachable ();
-
   if (!optimize)
 {
   flag_merge_constants = 0;

Processor for header files.

[James Courtier-Dutton]

Hi,

I am writing a decompiler for lib or .o files.
For the application developer, one would have the lib or .o file and a
.h file that would identify the api for the application developer to
use to make use of the lib or .o file.
For my decompiler, I therefore need to be able to process the .h
files, as they will obviously help with the decompiler task.
I know gcc processes .h header files, so I am hoping to use gcc's
already implemented header processor.
Can anyone point me to which part of the gcc source tree does the
task, and also what format the data is stored in once processed.

Kind Regards

James