Suggestion required for appropriate implementation
Hi All, I want to add command line options in GCC for analyzing application code for a set of rules. These options would generate warnings against the violated rules. I would like to give user provision of analyzing code for:- 1. Generating warnings for all the rules. 2. Enabling warning only for a particular rule. 3. Disabling warning for a particular rule. Please suggest me which of the following two approaches is appropriate in order to get approval from FSF. Approach 1: Since these options are warning options, I intend to integrate them with standard '-W' options of GCC. Doing so would by default give the user provision of suppressing warning for a particular rule by using '-Wno'. For e.g.: 1. If the user wants to analyze code for all rules, then he can do that by using '-Wanalyze' option. 2. If the user wants to analyze code for only rule 1, then he can do that by using '-Wanalyze-Rule1' option. 3. If the user wants to analyze code for all rules except rule 1, then he can do that by using '-Wanalyze' option followed by '-Wno-analyze-Rule1' option. This approach will add command line options equal to the number of rules. Kindly suggest whether adding so many options would be appropriate. In order to avoid these many options, I would like to change the syntax to '-Wanalyze-Rule='. Doing so would add only 1 command line option but it is not possible to have similar syntax for suppressing warning by using '-Wno-analyze-Rule='. Please confirm my understanding on the same. Approach 2: In order to overcome the drawback mentioned in the first approach, I intend to have a completely different syntax of command line option. This approach too will generate warnings against violated rules but the command line options will be completely independent of standard GCC '-W' options. For e.g.: 1. If the user wants to analyze code for all rules, then he can do that by using 'analyze-all' option. 2. If the user wants to analyze code for only rule 1, then he can do that by using 'enable-analyze-rule=1' option. 3. If the user wants to analyze code for all rules except rule 1, then he can do that by using 'analyze-all' option followed by 'disable-analyze-rule=1' option. I feel this approach is appropriate because this would add only 3 command line options whereas the number of command line options in first approach would be equal to the number of rules. Kindly suggest me which approach is appropriate and also your comments on the same in view of getting it approved by FSF. Regards, Rahul Phalak 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, 2006.
sorry, unimplemented: 64-bit mode not compiled in - ?!
I imagine a lot of you gcc people will laugh at me now,
but I finally bought amd64 machine and want
to compile 64-bit Linux kernel.
I am not able to do it. Tracked it down to a simple thing.
My gcc cannot compile any .c file with -m64 flag:
# gcc -m64 -c t.c
t.c:1: sorry, unimplemented: 64-bit mode not compiled in
I tried rebuilding my gcc for i686-pc-linux-gnu (was 486-... before),
doesn't change anything.
I looked in the source. i386.c:
if ((TARGET_64BIT != 0) != ((target_flags & MASK_64BIT) != 0))
sorry ("%i-bit mode not compiled in",
(target_flags & MASK_64BIT) ? 64 : 32);
does it mean I need a cross-compiler (to x86_64) to use -m64?
It's strange because then -m64 is not useful at all
- x86_64 cross compiler defaults to 64 bit anyway... right?
I also tried to find answer using google,
but to my surprise google did not immediately gave me
lots of links on "how to build x86_64 kernel on i386".
That's why I'm wasting your time by asking on a gcc ml.
An URL or googleable search string will suffice. Thank you.
--
vda
Re: sorry, unimplemented: 64-bit mode not compiled in - ?!
On Thu, Jul 27, 2006 at 12:56:14PM +0200, Denis Vlasenko wrote: > does it mean I need a cross-compiler (to x86_64) to use -m64? > It's strange because then -m64 is not useful at all > - x86_64 cross compiler defaults to 64 bit anyway... right? It overrides -m32 earlier on the command line. It's also possible to build 32-bit configurations which support 64-bit compilation - but the default i686-linux configuration does not. The i686-solaris2.10 port does, and Debian's i486-linux compilers do also (local patch). -- Daniel Jacobowitz CodeSourcery
building cross-compiler to x86_64. pthread.h: No such file
Hi, I am building gcc-4.1.1 like this: $SRC/configure \ --enable-languages="c,c++" \ --disable-nls \ --build=i386-pc-linux-gnu \ --host=i386-pc-linux-gnu\ --target=x86_64-pc-linux-gnu\ --disable-threads \ --with-system-zlib \ --enable-threads=posix \ "make all-gcc" dies like this: xgcc -B/.share/usr/src/gcc-4.1.1.obj-x86_64/./gcc/ -B/usr/app/gcc-4.1.1-x86_64/x86_64-pc-linux -gnu/bin/ -B/usr/app/gcc-4.1.1-x86_64/x86_64-pc-linux-gnu/lib/ -isystem /usr/app/gcc-4.1.1-x86_64/x86_64-pc-linux-gnu/include -isystem /u sr/app/gcc-4.1.1-x86_64/x86_64-pc-linux-gnu/sys-include -O2 -O2 -Os -falign-functions=1 -falign-labels=1 -falign-loops=1 -falign-jumps=1 -DIN_GCC -DCROSS_COMPILE -DNATIVE_CROSS -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -i system ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-4.1.1/gcc -I../.. /gcc-4.1.1/gcc/. -I../../gcc-4.1.1/gcc/../include -I../../gcc-4.1.1/gcc/../libcpp/include -fexceptions -fvisibility=hidden -DHIDE_EXPORT S -c ../../gcc-4.1.1/gcc/unwind-dw2.c -o libgcc/./unwind-dw2.o In file included from ./gthr-default.h:1, from ../../gcc-4.1.1/gcc/gthr.h:114, from ../../gcc-4.1.1/gcc/unwind-dw2.c:42: ../../gcc-4.1.1/gcc/gthr-posix.h:43:21: error: pthread.h: No such file or directory ../../gcc-4.1.1/gcc/gthr-posix.h:44:20: error: unistd.h: No such file or directory Lots of errors follows of course... I tried removing --with-system-zlib \ --enable-threads=posix \ but the problem is exactly the same. What gives? -- vda
Re: building cross-compiler to x86_64. pthread.h: No such file
On Thu, Jul 27, 2006 at 03:51:50PM +0200, Denis Vlasenko wrote: > ../../gcc-4.1.1/gcc/gthr-posix.h:43:21: error: pthread.h: No such file or > directory > ../../gcc-4.1.1/gcc/gthr-posix.h:44:20: error: unistd.h: No such file or > directory Please ask on gcc-help or the crossgcc list. This is a FAQ. -- Daniel Jacobowitz CodeSourcery
Re: Suggestion required for appropriate implementation
"Rahul Phalak" <[EMAIL PROTECTED]> writes: Please don't send e-mail to both gcc@gcc.gnu.org and [EMAIL PROTECTED] This type of e-mail, related to the development of gcc, is appropriate for [EMAIL PROTECTED] > Approach 1: > Since these options are warning options, I intend to integrate them with > standard '-W' options of GCC. Doing so would by default give the user > provision of suppressing warning for a particular rule by using '-Wno'. > > For e.g.: > 1. If the user wants to analyze code for all rules, then he can do that > by using '-Wanalyze' option. > 2. If the user wants to analyze code for only rule 1, then he can do > that by using '-Wanalyze-Rule1' option. > 3. If the user wants to analyze code for all rules except rule 1, then > he can do that by using '-Wanalyze' option followed by > '-Wno-analyze-Rule1' option. > > This approach will add command line options equal to the number of > rules. > Kindly suggest whether adding so many options would be appropriate. > In order to avoid these many options, I would like to change the syntax > to '-Wanalyze-Rule='. Doing so would add only 1 command > line option but it is not possible to have similar syntax for > suppressing warning by using '-Wno-analyze-Rule='. > Please confirm my understanding on the same. It's a little hard to know the best approach with no idea of what kinds of rules you are talking about. However, given that Using -W options is the right approach. I don't see any reason why -Wno-analyze-Rule= wouldn't work. Probably better would be -Wanalyze-all and -Wanalyze=RULE,RULE,RULE and -Wno-analyze=RULE,RULE,RULE where the rules have names. While I don't speak for all the gcc maintainers, I think it's very unlikely that we would a -Wanalyze option which took rule numbers, unless the numbers refer to a standard reference work along the lines of the -Weffc++ option. > 1. If the user wants to analyze code for all rules, then he can do that > by using 'analyze-all' option. > 2. If the user wants to analyze code for only rule 1, then he can do > that by using 'enable-analyze-rule=1' option. > 3. If the user wants to analyze code for all rules except rule 1, then > he can do that by using 'analyze-all' option followed by > 'disable-analyze-rule=1' option. You would need to make a very strong argument for adding a new kind of option to gcc. Perhaps the nature of the rules you are talking about makes this the right approach. However, based on what you've said so far, these sorts of option names would be inappropriate. Ian
New Ada testcases
I've started adding a bunch of regression tests to the
Ada dejagnu testsuite (see below for the current state).
I've accumulated these over several years, and almost all
of them have been reported in gcc bugzilla (not many of
these) or to ACT (the funny package names are ACT tracking
numbers).
However it's not clear to me how to add multi-package tests.
Some of my test cases consist of more than a_package.ads,
a_package.adb (think of tests involving interaction of child
packages with parent packages for example - they necessarily
involve several compilation units). Logically speaking, the
test only needs to be run on the main package, the subsidiary
packages don't need to be tested individually. However the
testsuite infrastructure tests all bodies. How to tell it
to ignore some? Likewise for tests in gnat.dg/specs.
Thanks for your help,
Duncan.
Index: testsuite/gnat.dg/f202_014.adb
===
--- testsuite/gnat.dg/f202_014.adb (revision 0)
+++ testsuite/gnat.dg/f202_014.adb (revision 0)
@@ -0,0 +1,12 @@
+-- Compiler crash.
+
+-- { dg-do compile }
+-- { dg-options "-gnat05" }
+
+package body F202_014 is
+ procedure R (X : access constant Integer) is
+ B : Boolean;
+ begin
+ B := X = I;
+ end;
+end;
Index: testsuite/gnat.dg/ec13_012.ads
===
--- testsuite/gnat.dg/ec13_012.ads (revision 0)
+++ testsuite/gnat.dg/ec13_012.ads (revision 0)
@@ -0,0 +1,2 @@
+function EC13_012 return Boolean;
+pragma Pure_Function (EC13_012);
Index: testsuite/gnat.dg/eb24_002.ads
===
--- testsuite/gnat.dg/eb24_002.ads (revision 0)
+++ testsuite/gnat.dg/eb24_002.ads (revision 0)
@@ -0,0 +1,2 @@
+procedure EB24_002;
+pragma Pure (EB24_002);
Index: testsuite/gnat.dg/e224_009.adb
===
--- testsuite/gnat.dg/e224_009.adb (revision 0)
+++ testsuite/gnat.dg/e224_009.adb (revision 0)
@@ -0,0 +1,16 @@
+-- Wrong warning.
+
+-- { dg-do compile }
+-- { dg-options "-gnatwa" }
+
+procedure E224_009 is
+ type R is record
+ I : Integer;
+ end record;
+ An_R : aliased R;
+ type R_P is access all R;
+ A : array (1 .. 1) of R_P;
+begin
+ A (1) := An_R'Access;
+ A (1).I := 2;
+end;
Index: testsuite/gnat.dg/f109_018.adb
===
--- testsuite/gnat.dg/f109_018.adb (revision 0)
+++ testsuite/gnat.dg/f109_018.adb (revision 0)
@@ -0,0 +1,13 @@
+-- Compiler crash.
+
+-- { dg-do compile }
+
+procedure F109_018 is
+ procedure Q (I : Integer) is
+ begin null; end;
+ procedure Q2 (I : Integer) renames Q;
+begin
+ if Q2'Mechanism_Code (1) = 1 then
+ null;
+ end if;
+end;
Index: testsuite/gnat.dg/eb30_003.adb
===
--- testsuite/gnat.dg/eb30_003.adb (revision 0)
+++ testsuite/gnat.dg/eb30_003.adb (revision 0)
@@ -0,0 +1,12 @@
+-- Compiler crash.
+
+-- { dg-do compile }
+-- { dg-options "-gnat05" }
+
+package body EB30_003 is
+ procedure F (A : A_Type) is
+ An_A : access A_Type;
+ begin
+ An_A := A.An_A;
+ end;
+end;
Index: testsuite/gnat.dg/eb14_003.adb
===
--- testsuite/gnat.dg/eb14_003.adb (revision 0)
+++ testsuite/gnat.dg/eb14_003.adb (revision 0)
@@ -0,0 +1,14 @@
+-- Program_Error, due to <> not default initializing the array elements.
+
+-- { dg-do run }
+-- { dg-options "-gnat05" }
+
+with Ada.Containers.Doubly_Linked_Lists;
+procedure EB14_003 is
+ package Lists is new Ada.Containers.Doubly_Linked_Lists (Boolean);
+ type Array_Type is array (Boolean) of Lists.List;
+ type Record_Type is record An_Array : Array_Type; end record;
+ A_Record : Record_Type := (An_Array => <>);
+begin
+ Lists.Append (A_Record.An_Array (True), True);
+end;
Index: testsuite/gnat.dg/f202_014.ads
===
--- testsuite/gnat.dg/f202_014.ads (revision 0)
+++ testsuite/gnat.dg/f202_014.ads (revision 0)
@@ -0,0 +1,5 @@
+package F202_014 is
+ type IA is access all Integer;
+ I : IA;
+ procedure R (X : access constant Integer);
+end;
Index: testsuite/gnat.dg/eb30_003.ads
===
--- testsuite/gnat.dg/eb30_003.ads (revision 0)
+++ testsuite/gnat.dg/eb30_003.ads (revision 0)
@@ -0,0 +1,6 @@
+package EB30_003 is
+ type A_Type is private;
+ procedure F (A : A_Type);
+private
+ type A_Type is record An_A : access A_Type; end record;
+end;
Index: testsuite/gnat.dg/e701_012.adb
===
--- testsuite/gnat.dg/e701_012.adb (revision 0)
+++ testsuite/gnat.dg/e701_012.adb (revision 0)
@@ -0,0 +1,11 @@
+--
Website Suggestion
Hello
My name is Joe Butch and I'm with LocalBuilders.com. Our site is
dedicated to informing the public about local builders as well as
providing the service of locating local builders and general
contractors for anyone in the United States.
We have recently come upon gnu.org and we believe that your site's
audience will take advantage of the service we provide. That's why we
would like to inform you about our site and to propose submitting our
link to your web page located at
http://gcc.gnu.org/ml/gcc/2006-02/msg00607.html
Our site information is:
URL: http://www.LocalBuilders.com
Title: General Contractor
Description: Find a general contractor or home builder specializing in
condo conversons, pools, decks and porches, roofing and gutters,
carpentry, painting, heaters and a/c, plumbing, remodeling and more.
We would appreciate it if you could include a link to our site on your
web page.
Thank you and all the folks at gnu.org for your time and consideration.
Sincerely,
Joe Butch
Local Builders
100 West Cypress Creek Rd. Suite 1050
Fort Lauderdale, Fl 33309
[EMAIL PROTECTED]
{To opt out from future emails, please reply to this message with
"Unsubscribe" in the subject box.}
Re: Suggestion required for appropriate implementation
On Jul 27, 2006, at 12:31 AM, Rahul Phalak wrote: I want to add command line options in GCC for analyzing application code for a set of rules. I agree with Ian for the most part. For research and development, you will want to give your users lots of control. They will then give you feedback as to which ones are useful and why and which sets work well together. For production, you'll want to group the useful sets together and have controls for only the high level sets. We'd be most interested in the result of the research and the high level sets. We prefer names over numbers to identify the sets.
Re: gcc visibility used by moz
Mark Mitchell <[EMAIL PROTECTED]> writes: > Jason Merrill wrote: > > > > It seems that you have a different mental model of type visibility. > > I've gotten a little lost in this thread. Is there a clear proposal for > the semantics that we're leaning towards at this point? > > One meta-note is that we're not the first people to consider this. I > wonder if the rules beginning at page 19 (Inter-DLL symbol visibility > and linkage) of the ARM C++ ABI: > > http://www.arm.com/miscPDFs/8033.pdf > > might be helpful? This is really about mapping dllexport/dllimport onto > ELF symbols, but there are some rules about how to decide whether > members of classes are exported. It looks like those rules are an attempt to explain Visual Studio-style linkage. If we're interested in having those, Apple's version of GCC implements them with the -fvisibility-ms-compat flag, plus documentation which explains what the flag does from a user point of view (which was by far the hardest part of the implementation of the flag).
Re: ld -shared -Bsymbolic and C++ shared library
"H. J. Lu" <[EMAIL PROTECTED]> writes: > ld -shared -Bsymbolic will reduce number of dynamic relocations in > a shared library. Unfortunately, it won't work correctly with C++ > exception and maybe other language features. > > However, I think it is possible to make -shared -Bsymbolic to work > for C++ by providing a way to specify a list of symbols which must > be dynamic. We then can do > > # g++ -Wl,-Bsymbolic -shared -xxx "list of dynamic symbols" -o libfoo.so ... > > and libfoo.so written in C++ will work correctly with much fewer dynamic > relocations. You may find this would be easier to use if you just had a flag which made -Bsymbolic apply only to non-weak symbols.
gcc-4.0-20060727 is now available
Snapshot gcc-4.0-20060727 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060727/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 115781 You'll find: gcc-4.0-20060727.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060727.tar.bz2 C front end and core compiler gcc-ada-4.0-20060727.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060727.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060727.tar.bz2 C++ front end and runtime gcc-java-4.0-20060727.tar.bz2 Java front end and runtime gcc-objc-4.0-20060727.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060727.tar.bz2The GCC testsuite Diffs from 4.0-20060720 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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: ld -shared -Bsymbolic and C++ shared library
On Thu, Jul 27, 2006 at 03:37:33PM -0700, Geoffrey Keating wrote: > "H. J. Lu" <[EMAIL PROTECTED]> writes: > > > ld -shared -Bsymbolic will reduce number of dynamic relocations in > > a shared library. Unfortunately, it won't work correctly with C++ > > exception and maybe other language features. > > > > However, I think it is possible to make -shared -Bsymbolic to work > > for C++ by providing a way to specify a list of symbols which must > > be dynamic. We then can do > > > > # g++ -Wl,-Bsymbolic -shared -xxx "list of dynamic symbols" -o libfoo.so ... > > > > and libfoo.so written in C++ will work correctly with much fewer dynamic > > relocations. > > You may find this would be easier to use if you just had a flag which > made -Bsymbolic apply only to non-weak symbols. It doesn't work since 1. There are weak function symbols, which we do want to bind locally. 2. Weak symbols aren't required for comdat group. BTW, -Wl,-Bsymbolic can't be used since it will add DF_SYMBOLIC to shared library, which will cause dynamic linker to resolve symbols locally. H.J.
RE: [cygwin/mingw32] DBX_REGISTER_NUMBER vs DWARF2_FRAME_REF_OUT
> > Date: Thu, 27 Jul 2006 09:46:36 +1200 > > From: Danny Smith <[EMAIL PROTECTED]> > > > > From: Mark Kettenis > > Sent: Thursday, July 27, 2006 9:34 AM > > > > > The best thing to do is probably to define > > > DWARF2_FRAME_REG_OUT to always use the SVR4 register map. > > > > Thanks for that advice. I'm in process of testing with > > the simple one-line change: > > > > #define DBX_REGISTER_NUMBER(n) svr4_dbx_register_map[n] > > That'd be bad, since it will break debugging code compiled > with -gstabs in a very confusing way. And it would be > impossible to fix in GDB without screwing over people that > are still using older versions of GCC. > It certainly is bad. This hasn't caused any problems yet. /* Maintain compatibility with old -gstabs code. */ #undef DBX_REGISTER_NUMBER #define DBX_REGISTER_NUMBER(n) (write_symbols == DWARF2_DEBUG \ ? svr4_dbx_register_map[(n)] \ : dbx_register_map[(n)]) /* Map gcc register number to DWARF 2 CFA column number. Always use the svr4_dbx_register_map for DWARF .eh_frame even if we don't use DWARF for debugging. */ #undef DWARF_FRAME_REGNUM #define DWARF_FRAME_REGNUM(n) svr4_dbx_register_map[(n)] Danny > Mark >
