_LARGE_FILES support in AIX -GCC compilation problem.
Hi All, I am using GCC 3.46 version for AIX 5.1 platform. I have used the -D_LARGE_FILES -D_LARGE_FILE_API as part of compiler options. Then i received the follwoing error: /opt/gccsrc1/GCC_INSTALL_DIR/lib/gcc/powerpc-ibm-aix5.1.0.0/3.4.6/../../../../include/c++/3.4.6/cstdio:108: error: `::fgetpos' has not been declared /opt/gccsrc1/GCC_INSTALL_DIR/lib/gcc/powerpc-ibm-aix5.1.0.0/3.4.6/../../../../include/c++/3.4.6/cstdio:110: error: `::fopen' has not been declared /opt/gccsrc1/GCC_INSTALL_DIR/lib/gcc/powerpc-ibm-aix5.1.0.0/3.4.6/../../../../include/c++/3.4.6/cstdio:115: error: `::freopen' has not been declared /opt/gccsrc1/GCC_INSTALL_DIR/lib/gcc/powerpc-ibm-aix5.1.0.0/3.4.6/../../../../include/c++/3.4.6/cstdio:118: error: `::fsetpos' has not been declared Is this the problem of GCC ? Is there any workaround , please help me to come up from this problem. Rgs, Kithsiri
RE: Suggestion required for appropriate implementation
Hi, >>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 The rules that I am talking about are the rules that will help user to write efficient code. For e.g. "Declare variables in descending order according to base type size." >>Using -W options is the right approach. I don't see any reason why -Wno-analyze-Rule= wouldn't work. The reason I felt that above syntax wouldn't work is:- According to the first syntax, Wanalyze-Rule1, Wanalyze-Rule2 etc are considered as seperate options in c.opt file. A seperate flag in the form of Var(flag) is associated with each of them. This flag is set to 1 or 0 depending on whether "-W" or "-Wno" is passed respectively. By doing so there is no seperate case required in common_handle_option() function in c-opts.c. While checking for a particular rule, the warning will be prompted only if the flag is set. While according to the second syntax, changing the implementation to Wanalyze-rule=1 will mean that all these options come under one common option in c.opt, that is Wanalyze-rule= . There will be no seperate flag like Var(flag) in this case. The will be handled in common_handle_option() function using a switch case.This would mean that the flag value will be an integer depending on number of the rule and not 0/1. Hence only "-W" will work in this case and not "-Wno". If "-Wno" is to be implemented then a seperate option has to be added in c.opt file like Wno-analyze-rule=. I did not find any such implementation done in c.opt file where "-Wno" is added as seperate option as "-W" by default has "-Wno" form. In the first syntax, seperate "-Wno" options are not required because "-W" by default has "-Wno" property. This property works only if value of flag is either 0 or 1. But the second syntax would change the value to an integer value starting from 1, so "-Wno" doesnt work. Please correct me if I am wrong in my understanding. 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. 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. "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 t
Re: sorry, unimplemented: 64-bit mode not compiled in - ?!
On Thursday 27 July 2006 15:44, Daniel Jacobowitz wrote: > 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. I did not understand this part. Who is "it"? gcc? I tried gcc -v -m64 -c t.c and I do not see -m32 anywhere... Oh well, never mind. > 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). Pity. Adding that to stock gcc would be nice. For the time being, I built x86_64 cross compiler and then I built the 64-bit Linux kernel. It works (apart from some minor trouble with sound driver). Thanks guys for your software! -- 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). Interesting, the major reason for disabling -m64 by default for 32bit compilers was the fact that it enforces HOST_WIDE_INT to be 64bit slowing down the whole compiler considerably. Are Debian's folks happy to wait longer for compilation or has this overhead changed? Honza > > -- > Daniel Jacobowitz > CodeSourcery
GCC missed optimization?
I've been doing some benchmarking of gfortran, and reducing the
testcase leads to what seems a missed optimization in the following
code:
$ cat a.c
void foo (float * restrict x, float * restrict y)
{
int i;
for (i = 0; i < 1; i++)
x[i] = y[i] * y[i];
}
$ gcc a.c -O1 -ffast-math -msse -mfpmath=sse -ftree-vectorize
-ftree-vectorizer-verbose=5 -std=c99 -c
a.c:5: note: Alignment of access forced using peeling.
a.c:5: note: Vectorizing an unaligned access.
a.c:5: note: not vectorized: relevant stmt not supported: D.1353_14 =
__builtin_powf (D.1352_13, 2.0e+0)
a.c:5: note: vectorized 0 loops in function.
I find in fold-const.c:fold_binary, around line 9091, I found the following:
/* Optimize x*x as pow(x,2.0), which is expanded as x*x. */
Should I file it as a missed-optimization bug in bugzilla, or is there
some clever reason for that behaviour?
FX
Re: sorry, unimplemented: 64-bit mode not compiled in - ?!
On 7/28/06, Jan Hubicka <[EMAIL PROTECTED]> wrote: > 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). Interesting, the major reason for disabling -m64 by default for 32bit compilers was the fact that it enforces HOST_WIDE_INT to be 64bit slowing down the whole compiler considerably. Are Debian's folks happy to wait longer for compilation or has this overhead changed? It also uses more memory due to this change. Richard.
Re: GCC missed optimization?
On 7/28/06, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
I've been doing some benchmarking of gfortran, and reducing the
testcase leads to what seems a missed optimization in the following
code:
$ cat a.c
void foo (float * restrict x, float * restrict y)
{
int i;
for (i = 0; i < 1; i++)
x[i] = y[i] * y[i];
}
$ gcc a.c -O1 -ffast-math -msse -mfpmath=sse -ftree-vectorize
-ftree-vectorizer-verbose=5 -std=c99 -c
a.c:5: note: Alignment of access forced using peeling.
a.c:5: note: Vectorizing an unaligned access.
a.c:5: note: not vectorized: relevant stmt not supported: D.1353_14 =
__builtin_powf (D.1352_13, 2.0e+0)
a.c:5: note: vectorized 0 loops in function.
I find in fold-const.c:fold_binary, around line 9091, I found the following:
/* Optimize x*x as pow(x,2.0), which is expanded as x*x. */
Should I file it as a missed-optimization bug in bugzilla, or is there
some clever reason for that behaviour?
It's canonicalization. I thought about folding to __builtin_powif
instead, which
would make it easier for the vectorizer to recognize it as x*x, which
it needs to
do in any case.
There was also a patch to expand those again at the tree level, which could be
done before the vectorizer.
A bugreport is useful so we don't forget.
Richard.
Re: sorry, unimplemented: 64-bit mode not compiled in - ?!
On Jul 28, 2006, at 2:44 AM, Jan Hubicka wrote: Interesting, the major reason for disabling -m64 by default for 32bit compilers was the fact that it enforces HOST_WIDE_INT to be 64bit slowing down the whole compiler considerably. Are Debian's folks happy to wait longer for compilation or has this overhead changed? Has anyone really done recent benchmarking of this claim because I think I filed the majority of the problems with HOST_WIDEST_FAST_INT. Though there might be other places which should use HOST_WIDEST_FAST_INT. -- Pinski
Re: GCC missed optimization?
On Jul 28, 2006, at 3:04 AM, Richard Guenther wrote: A bugreport is useful so we don't forget. There is already a bug report. PR 21465. -- Pinski
Re: sorry, unimplemented: 64-bit mode not compiled in - ?!
On Jul 28, 2006, at 3:01 AM, Richard Guenther wrote: It also uses more memory due to this change. I still have not seen any real data from this. All I have seen is talk. The memory usage has gone down with the change for RTL and also HOST_WIDEST_FAST_INT changes. Please provide evidence that it actually changes the memory usage significantly but saying it will. x86 is the only major native target which still uses 32bits for HOST_WIDE_INT. -- Pinski
Re: sorry, unimplemented: 64-bit mode not compiled in - ?!
On 7/28/06, Andrew Pinski <[EMAIL PROTECTED]> wrote: On Jul 28, 2006, at 3:01 AM, Richard Guenther wrote: > > It also uses more memory due to this change. I still have not seen any real data from this. All I have seen is talk. The memory usage has gone down with the change for RTL and also HOST_WIDEST_FAST_INT changes. Please provide evidence that it actually changes the memory usage significantly but saying it will. x86 is the only major native target which still uses 32bits for HOST_WIDE_INT. The memory requirement for PR12245 will nearly double. Richard.
Re: sorry, unimplemented: 64-bit mode not compiled in - ?!
On Jul 28, 2006, at 4:47 AM, Richard Guenther wrote: The memory requirement for PR12245 will nearly double. Saying it will double is not prove, please provide the memory usage dumps. If it does double then you should not be using x86 to optimize the memory usage and instead using powerpc-linux-gnu to do that work. -- Pinski
Re: sorry, unimplemented: 64-bit mode not compiled in - ?!
On Fri, Jul 28, 2006 at 11:44:12AM +0200, Jan Hubicka wrote: > Interesting, the major reason for disabling -m64 by default for 32bit > compilers was the fact that it enforces HOST_WIDE_INT to be 64bit > slowing down the whole compiler considerably. Are Debian's folks happy > to wait longer for compilation or has this overhead changed? They haven't done any measuring I know of, but we needed 64-bit compilers for a variety of reasons and this was much less disruptive than packaging a second copy of GCC. -- Daniel Jacobowitz CodeSourcery
Re: gcc-4.3 projects page?
Dan Kegel wrote: > Is it time to create a GCC_4.3_Projects page > like http://gcc.gnu.org/wiki/GCC_4.2_Projects ? > I imagine several projects are already in progress, > but not yet mentioned on the wiki... Yes, I've been thinking about doing that. It's fine with me if someone would like to create the page -- if not, I will take care of it shortly. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: _LARGE_FILES support in AIX -GCC compilation problem.
This is related to PR 20366. One needs to build the libraries and header files with -D_LARGE_FILE enabled, but this causes some conflicts which have not been resolved yet. David
Re: Suggestion required for appropriate implementation
"Rahul Phalak" <[EMAIL PROTECTED]> writes: > According to the first syntax, Wanalyze-Rule1, Wanalyze-Rule2 etc are > considered as seperate options in c.opt file. Look at Joined options. Consider -fbuiltin-abs -fno-builtin-memcpy. Ian
converting a CALL_EXPR node without any argument into SSA form, thanks
I asked the question about the name compatibility for CALL_EXPR in SSA form.
Thanks for the answers from this mailing list. My understanding is that we
don't need to convert a stmt node into SSA form as long as the call
instruction (CALL_EXPR) does not use any variable as an argument.
But the following simple example make GCC crash, the error is caused by
loop_commit_inserts () operation. i.e., when loop_commit_inserts () does
bsi_commit_inserts(), the internal data structure is not compatible. (Note:
stmt is a CALL_EXPR like void my_special_counter(void), which does not have
any argument.)
-
static
void inserting_call_expr(struct loops *loops){
tree functype;
tree stmt, decl;
basic_block src, dest, new_bb;
int i;
for (i = 1; i < loops->num; i++)
{
struct loop *loop = loops->parray[i];
edge e_instrument;
if (!loop)
continue;
e_instrument = loop_preheader_edge (loop);
functype = build_function_type (void_type_node, NULL_TREE);
decl = build_decl (FUNCTION_DECL, get_identifier
("my_special_counter"), functype);
stmt = build_function_call_expr (decl, NULL_TREE);
bsi_insert_on_edge(e_instrument, stmt);
}
loop_commit_inserts ();
}
--
Can someone give me some further info? I read the code in tree-ssa-*.c and
only found code that transforms MODIFY_EXPR nodes from GIMPLE IR to SSA
form, like this piece of code in tree-vect-transform.c
converting MODIFY_EXPR into SSA---
tmp = create_tmp_var (integer_type_node, "update");
add_referenced_tmp_var (tmp);
size = TYPE_SIZE (vect_ptr_type);
type = lang_hooks.types.type_for_size (tree_low_cst (size, 1), 1);
ptr_update = create_tmp_var (type, "update");
add_referenced_tmp_var (ptr_update);
vectype_size = TYPE_SIZE_UNIT (vectype);
vec_stmt = build2 (MULT_EXPR, integer_type_node, idx, vectype_size);
vec_stmt = build2 (MODIFY_EXPR, void_type_node, tmp, vec_stmt);
new_temp = make_ssa_name (tmp, vec_stmt);
TREE_OPERAND (vec_stmt, 0) = new_temp;
bsi_insert_before (bsi, vec_stmt, BSI_SAME_STMT);
-
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
gcc-4.1-20060728 is now available
Snapshot gcc-4.1-20060728 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060728/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 115801 You'll find: gcc-4.1-20060728.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060728.tar.bz2 C front end and core compiler gcc-ada-4.1-20060728.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060728.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060728.tar.bz2 C++ front end and runtime gcc-java-4.1-20060728.tar.bz2 Java front end and runtime gcc-objc-4.1-20060728.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060728.tar.bz2The GCC testsuite Diffs from 4.1-20060721 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
