Inserting new parameter in gcc
Hello to all, I have been working on inserting a new string argument in gcc, which accepts a string from command line. It would be like gcc ... -fmyparameter=stringtoread ... In common.opt, I have had to insert a new parameter, and it has been something like myparameter= Common RejectNegative Joined It works, but I have been thinking on it, and maybe this way to insert arguments is a little bit messy. For example, the keyword RejectNegative is not very intuitive, and the documentation about the options is a little bit confusing. Maybe this syntax should be improved, at least with better documentation, or maybe changing the syntax of common.opt (adding the same options with an intuitive form). I think it could be interesting to make a little patch about it. Opinions? Thanks Juan Luis
Re: Designs for better debug info in GCC
Hi,
On Thu, 8 Nov 2007, Alexandre Oliva wrote:
> > If you want to be really sure no arguments disappear (necessary for
> > instance for meaningful use of systemtap) you also need to inhibit
> > some transformations,
>
> I'm not aware of any situations in which we must force an argument not
> to disappear. All of the problems I'm aware of are those in which the
> argument is there, we're just missing debug information for it. If you
> have information about needs for preserving arguments that are actually
> dead, please send it my way.
static inline int foo(int i)
{
return i-1;
}
int foobar(int j)
{
return foo(j+2);
}
int main(int argc, char **argv)
{
return foobar(argc);
}
And similar examples. Depending on circumstances the formal argument 'i'
of "foo" might be optimized away. If you want to use systemtap to show
the actual arguments for all calls to foo, even the inlined ones, then you
somehow have to make sure that the value of 'i' itself is not optimized
away. Again, in this specific case, due to the simplicity of the involved
expression, it would theoretically be possible to express this with just
DWARF expressions (relating to the formal argument 'j' of foobar). In
more complicated situtation that's not possible anymore, at which point
you have to force the value of 'i' being live, if you want to be sure that
systemtap works in all cases.
> > during the next months, i.e. improve code quality at -O0 at least to a
> > point it was in the 3.x line of GCC.
>
> Aah, I guess the problem here is all the gimple-introduced temps,
> right? That our current -O0 is more like -O-1? :-)
Indeed :) Perhaps also doing a simple DCE and local regalloc, none of
which inhibits debugging.
Ciao,
Michael.
Re: Inserting new parameter in gcc
On 09/11/2007, Juan Luis Liarte <[EMAIL PROTECTED]> wrote: > Hello to all, > > myparameter= > Common RejectNegative Joined > > It works, but I have been thinking on it, and maybe this way to insert > arguments is a little bit messy. For example, the keyword RejectNegative > is not very intuitive, and the documentation about the options is a > little bit confusing. Why messy? On the contrary, I would suggest that it is too simple and we should have a more flexible syntax so we can auto-generate more code. RejectNegative is not intuitive? I really would like to hear your suggestion. Honestly, not sarcasm here. If you can improve the documentation, that is always welcome! Any small improvement! Even if you can't handle texinfo, documentation in the wiki is also welcome. > Maybe this syntax should be improved, at least with better > documentation, or maybe changing the syntax of common.opt (adding the > same options with an intuitive form). I think it could be interesting > to make a little patch about it. Opinions? Better documentation is always welcome. But if you can implement a new and better syntax, that would be welcomed too. Please, explain what that intuitive form could be. Also, you would need to be versed in awk, since the scripts that parse the *.opt files and generate C code for options are written in awk. Or alternatively, you would need to replace them with something else. But that won't be a little patch anymore. Cheers, Manuel.
Re: Inserting new parameter in gcc
Manuel López-Ibáñez wrote:
On 09/11/2007, Juan Luis Liarte <[EMAIL PROTECTED]> wrote:
(Strangely, I am subscribed to the gcc@gcc.gnu.org and did not get by
email Juan Luis' first message but I read it on the web
http://gcc.gnu.org/ml/gcc/2007-11/msg00266.html)
Hello to all,
myparameter=
Common RejectNegative Joined
It works, but I have been thinking on it, and maybe this way to insert
arguments is a little bit messy. For example, the keyword RejectNegative
is not very intuitive, and the documentation about the options is a
little bit confusing.
Why messy? On the contrary, I would suggest that it is too simple and
we should have a more flexible syntax so we can auto-generate more
code.
RejectNegative is not intuitive? I really would like to hear your
suggestion. Honestly, not sarcasm here.
I agree with the original poster Juan Luis Liarte, RejectNegative, as a
marker for string argument, is extremely counterintuitive: strings are
not negative (nor positive)! So I welcome another keyword form them.
Perhaps just StringArgument could be ok?
Is there some case where RejectNegative does what it suggest, ie accept
(only) numerical (integer) arguments and reject them if they are less
than 0?
But if you can implement a new and better syntax, that would be
welcomed too. Please, explain what that intuitive form could be.
Also, you would need to be versed in awk, since the scripts that parse
the *.opt files and generate C code for options are written in awk. Or
alternatively, you would need to replace them with something else. But
that won't be a little patch anymore.
Even if it is not a tiny patch, I would welcome it (but I am not in
position of formally approving it).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Inserting new parameter in gcc
On 09/11/2007, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote: > Manuel López-Ibáñez wrote: > > > > RejectNegative is not intuitive? I really would like to hear your > > suggestion. Honestly, not sarcasm here. > > I agree with the original poster Juan Luis Liarte, RejectNegative, as a > marker for string argument, is extremely counterintuitive: strings are > not negative (nor positive)! So I welcome another keyword form them. > Perhaps just StringArgument could be ok? > > Is there some case where RejectNegative does what it suggest, ie accept > (only) numerical (integer) arguments and reject them if they are less > than 0? Huh? RejectNegative rejects the negative form of a parameter. That is, -fno-myparameter won't be accepted. Having a negative form is the default for -f* and -W* parameters. I am not sure if that is documented but it should be documented and referenced at the beginning of every *.opt file. > > Also, you would need to be versed in awk, since the scripts that parse > > the *.opt files and generate C code for options are written in awk. Or > > alternatively, you would need to replace them with something else. But > > that won't be a little patch anymore. > Even if it is not a tiny patch, I would welcome it (but I am not in > position of formally approving it). I cannot be against a patch that hasn't even been described but keep in mind that tiny patches are: safer, easier to review and faster to approve. Documenting the current syntax would be an improvement. If you need help preparing a patch, just ask questions in this mailing list. Cheers, Manuel.
RE: Progress on GCC plugins ?
Mark Mitchell wrote: > Anyhow, in practical terms, debating this here probably will have zero > impact on the outcome. The ball is in RMS' court, and SC members > (including myself) have made many of the arguments that have been made > in this thread. If people want to influence the FSF, the best approach > is probably going to be sending mail directly to RMS, not discussing it > on this list. I think your opinion probably carries a bit more weight with RMS than mine. :-) I don't want to prolong a pointless discussion either, but I hope somebody has made the "forest through the trees" argument. Proprietary extensions using a standard plug-in interface will eventually get replaced by free ones if they're of value. In the long term, this type of direct assault on GPL would backfire in a big way. -Jerry
Re: Designs for better debug info in GCC
[Can we pick just gcc@ or just gcc-patches@ please?] On Thu, Nov 08, 2007 at 05:11:24PM -0800, Joe Buck wrote: > Debugging would be just as easy and natural if -O0 only made sure that > values of variables are written out to memory at positions where the > user can set a breakpoint; the code doesn't need to preserve every > operation exactly as written, or read variables in from memory that > are already in registers. Kind of an -O0.5 would be more desirable > than what we have now. Careful. Eliminating reads from memory messes up debugger modification of variables, unless you can explain to the debugger that the variable is currently in both locations - this has been discussed but AFAIK there is no representation for it yet. Changing the memory location won't change the next operation that thinks it's in the register. Changing the register will be lost later. -- Daniel Jacobowitz CodeSourcery
Re: Designs for better debug info in GCC
Daniel Jacobowitz wrote: Careful. Eliminating reads from memory messes up debugger modification of variables, unless you can explain to the debugger that the variable is currently in both locations - this has been discussed but AFAIK there is no representation for it yet. Changing the memory location won't change the next operation that thinks it's in the register. Changing the register will be lost later. I still think that changing memory locations is a marginal capability compared to reading them, and that is is fine if this capability is impacted by even low level optimization.
structuring a front-end subdirectory
Hello, As part of our Ada front-end maintainership, we (AdaCore) would like to introduce a subdirectory of 'ada' where we would relocate all the files implementing the Ada-front-end/GCC interface (the "gigi" sources for the internal GNAT/GCC tree interfacing, plus the build infrastructure bits: Make*.in and config-lang.in). This would be a first step in setting up a generally clearer organization of our sources and would help us move our internal trees from cvs to svn, which we are working on these days to enhance our patch submission/integration process. In our current experimental setups, only very few and simple changes to the language independant sources are necessary (one for sure, maybe two, depending on a choice to make), not at all Ada specific so of possible use to other front-ends. Before proceeding with a formal patch submission, we would appreciate feedback on the intent first and would be very happy to provide more details if need be, so ... Comments warmly welcome, Many thanks in advance, Olivier
Re: Inserting new parameter in gcc
Just to complete this discussion, the syntax of the *.opt files is (almost exactly) mapped by the gen-*.awk scripts into flags that are defined in the file gcc/opts.h. This file contains some comments about these flags: #define CL_PARAMS (1 << 18) /* Fake entry. Used to display --param info with --help. */ #define CL_WARNING (1 << 19) /* Enables an (optional) warning message. */ #define CL_OPTIMIZATION (1 << 20) /* Enables an (optional) optimization. */ #define CL_TARGET (1 << 21) /* Target-specific option. */ #define CL_COMMON (1 << 22) /* Language-independent. */ #define CL_MIN_OPTION_CLASS CL_PARAMS #define CL_MAX_OPTION_CLASS CL_COMMON /* From here on the bits describe attributes of the options. Before this point the bits have described the class of the option. This distinction is important because --help will not list options which only have these higher bits set. */ #define CL_DISABLED (1 << 23) /* Disabled in this configuration. */ #define CL_REPORT (1 << 24) /* Report argument with -fverbose-asm */ #define CL_JOINED (1 << 25) /* If takes joined argument. */ #define CL_SEPARATE (1 << 26) /* If takes a separate argument. */ #define CL_REJECT_NEGATIVE (1 << 27) /* Reject no- form. */ #define CL_MISSING_OK (1 << 28) /* Missing argument OK (joined). */ #define CL_UINTEGER (1 << 29) /* Argument is an integer >=0. */ #define CL_UNDOCUMENTED (1 << 30) /* Do not output with --help. */ Juan Luis, if you really want to contribute in this area, I would suggest to add a sentence to the *.opt files and the scripts pointing to gcc/opts.h and then improve the documentation there to mention the original syntax and how it maps into the flags (although in most cases it is pretty obvious: RejectNegative -> CL_REJECT_NEGATIVE). Nevertheless, this doesn't mean we are not open to suggestions on how to improve the current system. Thanks, Manuel.
Re: structuring a front-end subdirectory
On Fri, 9 Nov 2007, Olivier Hainque wrote: > As part of our Ada front-end maintainership, we (AdaCore) would like > to introduce a subdirectory of 'ada' where we would relocate all the > files implementing the Ada-front-end/GCC interface (the "gigi" sources > for the internal GNAT/GCC tree interfacing, plus the build > infrastructure bits: Make*.in and config-lang.in). If moving files, I'd encourage moving the sources built from the libada/ and gnattools/ toplevel directories to be physically located in those directories (or subdirectories of them) as far as possible, as one step in the rearrangement. I don't however know how much dependence there might be between these sources and the compiler sources that would make such a move difficult. Also note that, as described in gcc/doc/sourcebuild.texi, having gcc/ada/Makefile.in is deprecated, so I hope the rearrangement will eventually make it possible to eliminate this deprecated file (the only language remaining with its own Makefile.in). In any case, files should be moved with "svn mv" so that the history is properly maintained. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Reload using a live register to reload into
On Thu, Nov 08, 2007 at 09:52:27PM +0100, Eric Botcazou wrote: > > This doesnt happen because while inserting the caller save insn, its > > live_throughout is simply set to the live_throughout of the call insn > > + the registers marked with REG_DEAD notes in the call insn. > > Ouch. Relying on REG_DEAD notes to get complete liveness info is a no-no: > > /* The value in REG dies in this insn (i.e., it is not needed past >this insn). If REG is set in this insn, the REG_DEAD note may, >but need not, be omitted. */ > REG_NOTE (DEAD) > > This problem was apparently introduced a long time ago: > http://gcc.gnu.org/ml/gcc-cvs/1999-12/msg00212.html See also http://gcc.gnu.org/ml/gcc-patches/1999-11n/msg00916.html> and http://gcc.gnu.org/ml/gcc-patches/1999-12n/msg00086.html>. It's been on my TODO list for a year to essentially revert that patch and enhance find_reg() such that an output reload can use a register which is live_before && !live_after, which is not the case today. See e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725>. -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year
Newbie
Hi, Greatings everyone. I new on this mailnig list and I would like to help. I'm a french Phd student in computer science. I am familiar with grammar, compiler and language theory and I have some programming skills and some experience with the libc and GNU standard. If it is possible, I would like to begin with a small project to get familiar with GCC code. I have been through the "Simple GCC projects" web page and I would be interested in project such as "Convert reorg.c to use the flow graph". Could someone help me to get involved ? Thanks, Matthieu
Re: builtin_frame_address for stack pointer
skaller wrote: BTW: what happens on ia64 which has two? stacks? You have to search both stacks for GC roots. Only one stack is visible to normal user code, the regular program stack, and __builtin_frame_address(0) will point there. For the other stack, the backing store, you need some IA-64 specific code to get to it. You can use the __builtin_ia64_bsp() function, or you could write some assembly language code to read the ar.bsp register. Taking a quick look at boehm-gc, I see that there is a glibc hook it uses first, and then if that isn't available it tries to get the value from /proc/self/maps. Those are obviously linux specific solutions. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Bootstrap failure on i386-pc-solaris2.10
Hi.
My builds have been failing since about last night on my i386-pc-solaris2.10
system. I was able to build successfully yesterday - the compiler configuration
info is below:
$ gcc -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: /export/home/arth/gnu/gcc.git/configure
--enable-languages=c,c++,objc --disable-nls --disable-checking
--with-gmp=/usr/local --with-mpfr=/usr/local --enable-threads --with-gnu-as
--with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld
--disable-multilib --disable-libstdcxx-pch
Thread model: posix
gcc version 4.3.0 20071108 (experimental) (GCC)
$
Builds today fail during stage2 when compiling 'reg-stack.c'
$ make bootstrap-lean ...
{ ... lots of stuff snipped ... }
cc1: warnings being treated as errors
/export/home/arth/gnu/gcc.git/gcc/reg-stack.c: In function 'swap_to_top':
cc1: error: array subscript is below array bounds
{ ... more snippage as build stops ... }
make[3]: *** [reg-stack.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcov.pod fsf-funding.pod gfdl.pod cpp.pod gpl.pod gcc.pod
make[3]: Leaving directory `/export/home/arth/gnu/gcc-1109/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/export/home/arth/gnu/gcc-1109'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/export/home/arth/gnu/gcc-1109'
make: *** [bootstrap-lean] Error 2
$
I have been successfully building on a sparc-sun-solaris2.10 system with the
current code.
Anyone else seeing this failure?
--
Art Haas
Software Developer
ImpactWeather, Inc.
http://www.impactweather.com
Your Weather Department
gcc-4.3-20071109 is now available
Snapshot gcc-4.3-20071109 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20071109/ 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 130057 You'll find: gcc-4.3-20071109.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20071109.tar.bz2 C front end and core compiler gcc-ada-4.3-20071109.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20071109.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20071109.tar.bz2 C++ front end and runtime gcc-java-4.3-20071109.tar.bz2 Java front end and runtime gcc-objc-4.3-20071109.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20071109.tar.bz2The GCC testsuite Diffs from 4.3-20071102 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: Bootstrap failure on i386-pc-solaris2.10
Art Haas wrote:
Hi.
My builds have been failing since about last night on my i386-pc-solaris2.10
system. I was able to build successfully yesterday - the compiler configuration
info is below:
$ gcc -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: /export/home/arth/gnu/gcc.git/configure
--enable-languages=c,c++,objc --disable-nls --disable-checking
--with-gmp=/usr/local --with-mpfr=/usr/local --enable-threads --with-gnu-as
--with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld
--disable-multilib --disable-libstdcxx-pch
Thread model: posix
gcc version 4.3.0 20071108 (experimental) (GCC)
$
Builds today fail during stage2 when compiling 'reg-stack.c'
$ make bootstrap-lean ...
{ ... lots of stuff snipped ... }
cc1: warnings being treated as errors
/export/home/arth/gnu/gcc.git/gcc/reg-stack.c: In function 'swap_to_top':
cc1: error: array subscript is below array bounds
{ ... more snippage as build stops ... }
make[3]: *** [reg-stack.o] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcov.pod fsf-funding.pod gfdl.pod cpp.pod gpl.pod gcc.pod
make[3]: Leaving directory `/export/home/arth/gnu/gcc-1109/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/export/home/arth/gnu/gcc-1109'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/export/home/arth/gnu/gcc-1109'
make: *** [bootstrap-lean] Error 2
$
I have been successfully building on a sparc-sun-solaris2.10 system with the
current code.
Anyone else seeing this failure?
yep, on darwin-?86 with disable-checking, try w/o disable-checking.
Andreas
Re: gcc-4.3-20071109 is now available
I've submitted this snapshot to the Translation Project so translators can update translated messages in advance of the release (if the TP processes the snapshot, which didn't happen with two submitted in advance of the 4.2.0 release). I suggest we avoid bulk changes to existing messages now until after 4.3 branches, although of course bugs in messages can be fixed and bug fixes may add new diagnostics for things not previously diagnosed. -- Joseph S. Myers [EMAIL PROTECTED]
