Re: regmove fixups vs pseudos
DJ Delorie [EMAIL PROTECTED] writes: Any reason why we blindly assume destination registers will be hard registers here? Index: regmove.c === RCS file: /cvs/gcc/gcc/gcc/regmove.c,v retrieving revision 1.173 diff -p -U3 -r1.173 regmove.c --- regmove.c 25 Aug 2005 06:44:09 - 1.173 +++ regmove.c 14 Sep 2005 00:27:34 - @@ -1020,7 +1020,8 @@ fixup_match_2 (rtx insn, rtx dst, rtx sr if (REG_N_CALLS_CROSSED (REGNO (src)) == 0) break; - if (call_used_regs [REGNO (dst)] + if ((REGNO(dst) FIRST_PSEUDO_REGISTER + call_used_regs [REGNO (dst)]) || find_reg_fusage (p, CLOBBER, dst)) break; } The destination register which is set by a CALL will normally be FUNCTION_VALUE, which is normally a hard register. Do you have an example in which something else happens? Ian
help: interfacing between C and fortran program
Hi, I have a function written in fortran say fun(x, y), with x and y as integer (scalars) . Function returns integer. I need to call this function from a C program. How do I do it. Can some one help me. Does Gfortran and gcc support this. ?? Regards Gaurav
Re: help: interfacing between C and fortran program
Am Mittwoch, 14. September 2005 08:39 schrieb Gaurav Gautam, Noida: Hi, I have a function written in fortran say fun(x, y), with x and y as integer (scalars) . Function returns integer. I need to call this function from a C program. How do I do it. Can some one help me. Does Gfortran and gcc support this. ?? Regards Gaurav Yes, of course you can interface the function from C. There are some hints how to write the exact interface prototypes for your C/C++ function declaration on the `info g77' info pages. You should try to use f2c to generate your interfaces at least for the first time. See the hints on the info pages: # info g77 Other Languages Interoperating There you will find all you need ! pgpHXFOExhdbw.pgp Description: PGP signature
Re: Loop information
Hello, Can someone please help me getting the following information? 1) I would like to obtain the loop bounds (constant case) of all nested loops of a RTL insn. Is there a data structure over which I can iterate to get bounds for each nested loop of a RTL insn? 3) Can I determine if a pseudo register (RTX) is an induction variable (linear) or not? Which data structure gives me this information? see loop-iv.c (or a bit improved version of it on killloop-branch). You can analyze induction variables and determine # of iterations of a loop using it, which should give you the information you need. But the rtl level iv analysis is not too powerful, just sufficiently for the current uses. 2) Is there a way of determining sequences as mentioned in the paper Beyond Induction Variables: Detecting and Classifying Sequences Using a Demand-Driven SSA From by Gerlek, Stoltz and Wolfe? Not on RTL level. On tree level, see tree-scalar-evolutions.c 4) At RTL level, array accesses convert to MEM expressions. I was wondering if I can obtain the source level array name from the MEM expression. You might be able to extract this information from MEM_EXPR. Zdenek
Re: help: interfacing between C and fortran program
Ingo Krabbe wrote: Am Mittwoch, 14. September 2005 08:39 schrieb Gaurav Gautam, Noida: I have a function written in fortran say fun(x, y), with x and y as integer (scalars) . Function returns integer. I need to call this function from a C program. How do I do it. Can some one help me. Does Gfortran and gcc support this. ?? ... # info g77 Other Languages Interoperating There you will find all you need ! Except for a few differences, which will probably not affect you, see the documentation of the -ff2c command-line option of gfortran. Additionally, procedures which require an explicit interface (and which therefore couldn't be written in Fortran 77) pass array descriptors. Those are not documented outside gfortran's source code. - Tobi
Re: Introduction of GCC improvement work for Itanium via Gelato Federation
Gerald Pfeifer wrote: (If so, I'm wondering what it's going to buy the interested parties, because I have a hard time seeing one of the large GNU/Linux distributors switching to a compiler different from FSF GCC for Itanium.) Surely this depends on relative performance ...
Re: Introduction of GCC improvement work for Itanium via Gelato Federation
On Wednesday 14 September 2005 10:53, Robert Dewar wrote: Gerald Pfeifer wrote: (If so, I'm wondering what it's going to buy the interested parties, because I have a hard time seeing one of the large GNU/Linux distributors switching to a compiler different from FSF GCC for Itanium.) Surely this depends on relative performance ... My guess is that there are more important things than performance, such as stability, community support, maintenance burden, etc. Or let's put it this way: Would AdaCore have the resources to support two entirely different backends. Would it even want to hire new engineers or let its existing work-force learn compiler internals of another compiler to support just one target? I don't think so. Gr. Steven
RE: coding style: type* variable or type *varible
Original Message From: Mike Stump Sent: 13 September 2005 20:28 On Sep 13, 2005, at 12:23 PM, Rafael Espíndola wrote: I have seen both in gcc. I have found that type* variable is preferred in C++ code but I haven't found any guidelines for C code. If you ask gcc, you find: mrs $ grep 'int\* ' *.c | wc -l 4 mrs $ grep 'int \*' *.c | wc -l 369 pretty clear to me. I was rather surprised, on reviewing the GNU coding standards, that it doesn't actually mention this. As far as I could find in a quick skim through. Perhaps it should. IMO (and this is a _very_ IMO subject, so I acknowledge in advance that there is no one true way and that I may feel so but other people may feel differently), the argument for making the asterisk abut the variable name rather than the type is because the pointer-ness is indeed part of the particular variable rather than of the type, and it can be summed up in one simple question: char* a, b, c; Why should we want a, b and c to look the same, when a is different from the other two? cheers, DaveK -- Can't think of a witty .sigline today
Re: coding style: type* variable or type *varible
Dave Korn wrote: char* a, b, c; clearly we cannot allow this confusing notation, indeed this is a strong argument for char *a; which is really more in C style anyway I think.
Re: regmove fixups vs pseudos
Ian Lance Taylor ian@airs.com wrote: Any reason why we blindly assume destination registers will be hard registers here? Index: regmove.c === RCS file: /cvs/gcc/gcc/gcc/regmove.c,v retrieving revision 1.173 diff -p -U3 -r1.173 regmove.c --- regmove.c 25 Aug 2005 06:44:09 - 1.173 +++ regmove.c 14 Sep 2005 00:27:34 - @@ -1020,7 +1020,8 @@ fixup_match_2 (rtx insn, rtx dst, rtx sr if (REG_N_CALLS_CROSSED (REGNO (src)) == 0) break; - if (call_used_regs [REGNO (dst)] + if ((REGNO(dst) FIRST_PSEUDO_REGISTER + call_used_regs [REGNO (dst)]) || find_reg_fusage (p, CLOBBER, dst)) break; } The destination register which is set by a CALL will normally be FUNCTION_VALUE, which is normally a hard register. gcc_assert? -- Giovanni Bajo
Re: coding style: type* variable or type *varible
Dave Korn wrote: Original Message From: Mike Stump Sent: 13 September 2005 20:28 On Sep 13, 2005, at 12:23 PM, Rafael Espíndola wrote: I have seen both in gcc. I have found that type* variable is preferred in C++ code but I haven't found any guidelines for C code. If you ask gcc, you find: mrs $ grep 'int\* ' *.c | wc -l 4 mrs $ grep 'int \*' *.c | wc -l 369 pretty clear to me. My two cents... Well, for my version of gcc (gcc-4.1-20050528), I only get 3 'int*', and all the three are in comments, not in C code. I also get 10 'int * '. By my side, the only place I put int* is for casts. Regards, -- Yannick
RE: var_args for rs6000 backend
Sorry for delayed reply.
As I said, I haven't looked at the code in awhile (before GIMPLE), but
the TREE code is the symbol table that allows you to look up the types
of arguments and the function return type.
Yes, I think you ar right. I found some other functionalities in
rs6000_gimplify_va_arg() of TREE, but I am not sure of it , could you have
a look at it and verify my thoughts to it. Some code listed here for
your reference.
5784 t = fold_convert (TREE_TYPE (reg), size_int (8 - n_reg + 1));
5785 t = build2 (GE_EXPR, boolean_type_node, u, t);
5786 u = build1 (GOTO_EXPR, void_type_node, lab_false);
5787 t = build3 (COND_EXPR, void_type_node, t, u, NULL_TREE);
5788 gimplify_and_add (t, pre_p);
I can not find any document to explain these routines and just infer the
meaning literally. When this slice of code executed, the structure of tree
is like this,
COND_EXPR
/\
/ \
GOTO_EXPR GE_EXPR
Am I missing some thing? Anyone could approve or deny this. On the
presumption I am on right track, I do not know why compute
(8 - n_reg + 1) in compile-time and convert to TREE_TYPE (reg)?
The RTX code are the
instructions you produce for va_arg, etc. For example, I believe the
eabi/System V had a structure that had a few elements, one of which was
the argument number, then there pointers to the save areas for gpr and
fpr registers and the stack frame. The va_arg code would have to
produce code that tested the argument number, and if it was the first 8
arguments it would use the pointer to the gpr/fpr save areas and if not
it would use the stack pointer, and finally bump up the argument number.
Yes, I have got something in my mind about you have pointed out, but
there is another concept confused me, align. For example,
5820 t = ovf;
5821 if (align != 1)
5822 {
5823 t = build2 (PLUS_EXPR, TREE_TYPE (t), t, size_int (align -
1));
5824 t = build2 (BIT_AND_EXPR, TREE_TYPE (t), t,
5825 build_int_cst (NULL_TREE, -align));
5826 }
I do not know why align is relative to PLUS and BIT_AND, just for
alignment adjustment?
I may be somewhat wrong on the details. That is the trouble on working
on quite a few different ports -- after awhile all of the details blend
together.
Best Regards
Yao Qi
Bejing Institute of Technology
_
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
CFLAGS in one-tree style cross builds w/ newlib
Hi, As it seems to me, CFLAGS handling with newlib+gcc-4.0.x one-tree style cross-builds seems broken. So far I have tried different permutations of setting CFLAGS, CFLAGS_FOR_BUILD, CFLAGS_FOR_HOST and CFLAGS_FOR_TARGET, but have not been successful so far. Therefore - question: How is one supposed to pass custom CFLAGS to the host-compiled components in GCC without breaking newlib? Ralf
Re: regmove fixups vs pseudos
The destination register which is set by a CALL will normally be FUNCTION_VALUE, which is normally a hard register. dst is not the destination of the call, it's the destination of the SET/PLUS that's being optimized.
Re: Introduction of GCC improvement work for Itanium via Gelato Federation
On Wed, Sep 14, 2005 at 11:05:39AM +0200, Steven Bosscher wrote: On Wednesday 14 September 2005 10:53, Robert Dewar wrote: Gerald Pfeifer wrote: (If so, I'm wondering what it's going to buy the interested parties, because I have a hard time seeing one of the large GNU/Linux distributors switching to a compiler different from FSF GCC for Itanium.) Surely this depends on relative performance ... My guess is that there are more important things than performance, such as stability, community support, maintenance burden, etc. Or let's put it this way: Would AdaCore have the resources to support two entirely different backends. Would it even want to hire new engineers or let its existing work-force learn compiler internals of another compiler to support just one target? I don't think so. In practice: depends how much sales volume is in question... I can certainly see one of the enterprise Linux distributors, i.e. the people who have customers really interested in ia64 performance, taking this step. In theory. In practice that'd mean mostly SuSE and Red Hat, which puts it in a different light given the people and policies involved. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Introduction of GCC improvement work for Itanium via Gelato Federation
Steven Bosscher wrote: On Wednesday 14 September 2005 10:53, Robert Dewar wrote: Gerald Pfeifer wrote: (If so, I'm wondering what it's going to buy the interested parties, because I have a hard time seeing one of the large GNU/Linux distributors switching to a compiler different from FSF GCC for Itanium.) Surely this depends on relative performance ... My guess is that there are more important things than performance, such as stability, community support, maintenance burden, etc. I would add single compiler for other linux (and non-linux) ports, more compact code for Itanium (sometimes 2 times more compact), many additional features (last ones are mudflap and stack protector). If it was perfomance only, people would have switched to Intel, ORC or Openimpact compilers long ago. But according Gelato poll, most of Itanium users (like 70%) prefer to use gcc than other compilers.
GCC 4.0.2 RC1 Available
GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org, in the: pub/gcc/prerelease-4.0.2-20050913/ subdirectory. It's important to test the actual tarballs, rather than CVS, to check for any packaging issues. If you can, download and build the tarballs, post test results to the gcc-testresults mailing list with and contrib/test_summary. If you encounter problems, please file them in bugzilla, and add me to the CC: list. Assuming that no critical problems emerge, I'll do the final release within the next week. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: [gelato-gcc] Re: Introduction of GCC improvement work for Itanium via Gelato Federation
I agree with Vladimir wholeheartedly. After working on OpenIMPACT for years, I reached the conclusion that the ONLY way to make a real difference for Linux Itanium users is to help improve the mainstream GCC compiler. That is why my team (esp. Bob Kidd) is actively helping with a strong superblock path in GCC. As you know, the superblock techniques originated in IMPACT more than 12 years ago. We will be glad to work with the community to improve other aspects of the the GCC (interprocedural pointer analysis, array dependence, memory dataflow, etc.) based on our experience with IMPACT in the future. I personally see OpenIMPACT as proving ground for techniques and GCC as the real delivery vehicle for the software base. Regards, wen-mei At 08:49 AM 9/14/2005, Vladimir Makarov wrote: Steven Bosscher wrote: On Wednesday 14 September 2005 10:53, Robert Dewar wrote: Gerald Pfeifer wrote: (If so, I'm wondering what it's going to buy the interested parties, because I have a hard time seeing one of the large GNU/Linux distributors switching to a compiler different from FSF GCC for Itanium.) Surely this depends on relative performance ... My guess is that there are more important things than performance, such as stability, community support, maintenance burden, etc. I would add single compiler for other linux (and non-linux) ports, more compact code for Itanium (sometimes 2 times more compact), many additional features (last ones are mudflap and stack protector). If it was perfomance only, people would have switched to Intel, ORC or Openimpact compilers long ago. But according Gelato poll, most of Itanium users (like 70%) prefer to use gcc than other compilers. ___ Gelato-gcc mailing list [EMAIL PROTECTED] https://www.gelato.unsw.edu.au/mailman/listinfo/gelato-gcc
Re: coding style: type* variable or type *varible
On 09/14/2005 04:46 AM, Dave Korn wrote: [snip] IMO (and this is a _very_ IMO subject, so I acknowledge in advance that there is no one true way and that I may feel so but other people may feel differently), the argument for making the asterisk abut the variable name rather than the type is because the pointer-ness is indeed part of the particular variable rather than of the type, and it can be summed up in one simple question: char* a, b, c; Why should we want a, b and c to look the same, when a is different from the other two? True, but then this would be confusing: typedef char* charp; charp a, b, c; IIUC, this declares all a, b, and c as char*; yet, the only difference is the typedef is used to abbreviate the type. Maybe only a single variable should be declared per statement, e.g.: char* a; char b; char c; This is more typing but less confusion.
On which platforms is -fvisibility supported?
Hi, I've asked this question twice at gcc-help, but got no response. On which platforms is the -fvisibility option supported? The GCC docs here (http://tinyurl.com/99wc8) suggest that it is a subset of ELF platforms. Is that correct? -- Jonathan Turkanis www.kangaroologic.com
Corrupted CVS respository?
As of Wed Sep 14 08:55:04 PDT 2005, I got # ./contrib/gcc_update ... P gcc/version.c cvs [update aborted]: branch attribute does not match file for `/cvs/gcc/gcc/zlib/contrib/dotzlib/DotZLib.build,v' Has anyone else seen it? H.J.
Re: coding style: type* variable or type *varible
This has gone off-topic. Please continue elsewhere.
Symbolic replacement
Hi, I am trying to find out whats the best way to do the following. I want to replace some pre-defined variables at a few pre-defined line with a new temperory variable. I guess the front-end should be the best place to do it. Do I need to do this for each rule in c-parse.y ? Is there a more simpler and common way to handle it. ? thanks for any suggestions Shrey
Re: Corrupted CVS respository?
On Wed, 14 Sep 2005, H. J. Lu wrote: As of Wed Sep 14 08:55:04 PDT 2005, I got # ./contrib/gcc_update ... P gcc/version.c cvs [update aborted]: branch attribute does not match file for `/cvs/gcc/gcc/zlib/contrib/dotzlib/DotZLib.build,v' Has anyone else seen it? Overseers has been noified already. It's just the result of some caching done, and sometimes gets out of whack.
Re: coding style: type* variable or type *varible
Larry Evans wrote: IIUC, this declares all a, b, and c as char*; yet, the only difference is the typedef is used to abbreviate the type as expected, typedef is not like #define, I don't see a problem here
Re: Introduction of GCC improvement work for Itanium via Gelato Federation
Daniel Jacobowitz wrote: Or let's put it this way: Would AdaCore have the resources to support two entirely different backends. Would it even want to hire new engineers or let its existing work-force learn compiler internals of another compiler to support just one target? I don't think so. The answer is simple, depends on $$$ as with most other things. In practice I don't think our ia64 customers are that performance sensitive, at least not so far.
Re: regmove fixups vs pseudos
DJ Delorie [EMAIL PROTECTED] writes: The destination register which is set by a CALL will normally be FUNCTION_VALUE, which is normally a hard register. dst is not the destination of the call, it's the destination of the SET/PLUS that's being optimized. Sorry, I misread. In fact, you're right, this seems clearly wrong, since the only caller of fixup_match_2 actually checks to avoid passing in a hard register. Ian
Re: When is it legal to compare any pair of pointers?
On Sep 13, 2005, Daniel Jacobowitz [EMAIL PROTECTED] wrote: This bit binutils, in the form of a crash in a hash function on Solaris. I think that was pointer subtraction, rather than comparison, however. Perhaps someone who remembers this problem more clearly than I do can chip in if I've gotten it totally wrong. Yep, it was pointer subtraction, and GCC actually optimized the division, that could in theory be assumed to be exact, into a multiplication by a large constant (aah, the wonders of modulo arithmetics :-), and that's what broke some sorting function on Solaris. And I was the lucky guy who got to debug that :-) -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: CFLAGS in one-tree style cross builds w/ newlib
Ralf Corsepius [EMAIL PROTECTED] writes: As it seems to me, CFLAGS handling with newlib+gcc-4.0.x one-tree style cross-builds seems broken. So far I have tried different permutations of setting CFLAGS, CFLAGS_FOR_BUILD, CFLAGS_FOR_HOST and CFLAGS_FOR_TARGET, but have not been successful so far. Therefore - question: How is one supposed to pass custom CFLAGS to the host-compiled components in GCC without breaking newlib? Usually by wrapping them in CC: make CC=gcc -foobar We could introduce CFLAGS_FOR_HOST. The main problem is that we would have to use it practically everywhere. Ian
Re: When is it legal to compare any pair of pointers?
On Wed, Sep 14, 2005 at 02:15:43PM -0300, Alexandre Oliva wrote: On Sep 13, 2005, Daniel Jacobowitz [EMAIL PROTECTED] wrote: This bit binutils, in the form of a crash in a hash function on Solaris. I think that was pointer subtraction, rather than comparison, however. Perhaps someone who remembers this problem more clearly than I do can chip in if I've gotten it totally wrong. Yep, it was pointer subtraction, and GCC actually optimized the division, that could in theory be assumed to be exact, into a multiplication by a large constant (aah, the wonders of modulo arithmetics :-), and that's what broke some sorting function on Solaris. And I was the lucky guy who got to debug that :-) People that don't like the GCC optimization should be prepared to take a very large speed penalty on inner loops that have a pointer subtraction for an array or std::vector of objects whose size is not a power of two. There are processors where integer division is 20x slower than integer multiplication, or even more.
Gcc 4.0.2 RC1 checking not disabled?
Ave gcc people Build environment: -Redhat 7.3 with fedora legacy updates. -gcc build configured with : ../configure --prefix=/opt/gcc-4.0.2-RC1 --enable-languages=c,c++ --enable-threads=posix --disable-shared My build of gcc 4.0.2 RC1 is still bootstrapping but I see these snippets in my log. knipperdeknip make CC=gcc libdir=/opt/gcc-4.0.2-RC1/lib LANGUAGES=c \ CFLAGS=-g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING \ MAKEINFO=/tmp/workdir/gcc-4.0.2-20050913/missing makeinfo --split-size COVERAGE_FLAGS= OBJS-onestep=tree-chrec.o tree-scalar-evolution.o tree make[2]: Entering directory `/tmp/workdir/gcc-4.0.2-20050913/objdir/gcc' /knipperdeknip Is -DENABLE_CHECKING supposed to happen in a RC/release? Or has -DENABLE_CHECKING nothing to do with the configure option --enable-checking? Greetz Mu
RE: Gcc 4.0.2 RC1 checking not disabled?
Original Message
From: Gcc K6 testing account
Sent: 14 September 2005 19:43
Ave gcc people
¡Hola!
Is -DENABLE_CHECKING supposed to happen in a RC/release?
Or has -DENABLE_CHECKING nothing to do with the configure
option --enable-checking?
--enable-checking defaults to on these days, and has done for some time.
It doesn't enable _all_ the checking options by default, just some of the
most useful ones.
http://gcc.gnu.org/install/configure.html
-enable-checking
--enable-checking=list
When you specify this option, the compiler is built to perform internal
consistency checks of the requested complexity. This does not change the
generated code, but adds error checking within the compiler. This will slow
down the compiler and may only work properly if you are building the
compiler with GCC. This is `yes' by default when building from CVS or
snapshots, but `release' for releases. The categories of checks available
are `yes' (most common checks `assert,misc,tree,gc,rtlflag,runtime'), `no'
(no checks at all), `all' (all but `valgrind'), `release' (cheapest checks
`assert,runtime') or `none' (same as `no'). Individual checks can be enabled
with these flags `assert', `fold', `gc', `gcac' `misc', `rtl', `rtlflag',
`runtime', `tree', and `valgrind'.
which matches up nicely with the -DENABLE_CHECKING
-DENABLE_ASSERT_CHECKING that you are seeing ('release' category).
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Gcc 4.0.2 RC1 checking not disabled?
Original Message From: Gcc K6 testing account Sent: 14 September 2005 19:43 Ave gcc people ¡Hola! Is -DENABLE_CHECKING supposed to happen in a RC/release? Or has -DENABLE_CHECKING nothing to do with the configure option --enable-checking? --enable-checking defaults to on these days, and has done for some time. It doesn't enable _all_ the checking options by default, just some of the most useful ones. Actually that is not true. It defaults to --enable-checking=release for release branches with building with normal checking on stage1. Thanks, Andrew Pinski
Request link to www.devicetools.com
Dear Sir or Madam, DeviceTools (www.devicetools.com) is a comprehensive, free resources portal for the connected device developers. It includes software tools, silicon, resources and information for engineers building embedded devices. We would like to ask you add a link from your site http://gcc.gnu.org/readings.html to http://www.devicetools.com. This will provide your visitors immediate access to wealth of information and resources. I will be happy to put a link back to http://gcc.gnu.org/readings.html in return. Thank you for your cooperation, Dave Scop DeviceTools Team
RE: Gcc 4.0.2 RC1 checking not disabled?
Original Message From: Andrew Pinski Sent: 14 September 2005 19:56 Original Message From: Gcc K6 testing account Sent: 14 September 2005 19:43 Ave gcc people !Hola! Is -DENABLE_CHECKING supposed to happen in a RC/release? Or has -DENABLE_CHECKING nothing to do with the configure option --enable-checking? --enable-checking defaults to on these days, and has done for some time. It doesn't enable _all_ the checking options by default, just some of the most useful ones. Actually that is not true. It defaults to --enable-checking=release for release branches with building with normal checking on stage1. I think this may just be a subtlety of wording; I don't mean the same by --enable-checking defaults to on these days as I would by saying --enable-checking defaults to on these days In the first form, I'm just saying that it is enabled in any way at all; in the second form, I'm specifying the actual value of the parameter. cheers, DaveK -- Can't think of a witty .sigline today
RE: Gcc 4.0.2 RC1 checking not disabled?
On Wed, 14 Sep 2005, Dave Korn wrote:
Original Message
From: Gcc K6 testing account
Sent: 14 September 2005 19:43
Ave gcc people
¡Hola!
Is -DENABLE_CHECKING supposed to happen in a RC/release?
Or has -DENABLE_CHECKING nothing to do with the configure
option --enable-checking?
--enable-checking defaults to on these days, and has done for some time.
It doesn't enable _all_ the checking options by default, just some of the
most useful ones.
http://gcc.gnu.org/install/configure.html
-enable-checking
--enable-checking=list
When you specify this option, the compiler is built to perform internal
consistency checks of the requested complexity. This does not change the
generated code, but adds error checking within the compiler. This will slow
down the compiler and may only work properly if you are building the
compiler with GCC. This is `yes' by default when building from CVS or
snapshots, but `release' for releases. The categories of checks available
are `yes' (most common checks `assert,misc,tree,gc,rtlflag,runtime'), `no'
(no checks at all), `all' (all but `valgrind'), `release' (cheapest checks
`assert,runtime') or `none' (same as `no'). Individual checks can be enabled
with these flags `assert', `fold', `gc', `gcac' `misc', `rtl', `rtlflag',
`runtime', `tree', and `valgrind'.
which matches up nicely with the -DENABLE_CHECKING
-DENABLE_ASSERT_CHECKING that you are seeing ('release' category).
cheers,
DaveK
AHA!!!
I always assumed (without reading the docs!) that the default was
--disable-checking in a release/RC tarball and --enable-checking in CVS.
Sometimes reading the Fine Manual does help indeed :)
Thanx Mu
Re: Any plan to support Windows/x86-64?
On Tue, Sep 13, 2005 at 12:26:43PM -0400, Ross Ridge wrote: Is there any plan to support Windows/x86-64? I haven't heard of anyone wanting to work on such a port. What are needed for the port? What you'ld need for any OS port. GCC needs to support the Windows x64 ABI, you need a suitable runtime library, and you need a suitable assembler and linker. I'm not sure how close the Windows x64 ABI is to the x86-64 ABI, but it seems to be a fair bit different. Porting MinGW should be the simplest way to get a suitable runtime library, though maybe you'ld want to use a newer version of the Microsoft C runtime libary. Using binutils as the assembler and linker is pretty much a given, but they'd need to be ported to support the Windows x64 PE32+ PECOFF, if they don't already. FWIW, the most recent Cygwin snapshot (which will soon be Cygwin 1.5.19) works fairly well on Windows 64 so it is possible to have a linux-like environment on Windows 64 if someone wanted to develop there. It's probably easier to just develop on Linux using a cross compiler, though. Porting MinGW is definitely the way to go. It will be a major effort to get Cygwin working as a true 64-bit app. cgf
Re: Symbolic replacement
On 9/14/05, shreyas krishnan [EMAIL PROTECTED] wrote: Hi, I am trying to find out whats the best way to do the following. I want to replace some pre-defined variables at a few pre-defined line with a new temperory variable. I guess the front-end should be the best place to do it. Do I need to do this for each rule in c-parse.y ? Is there a more simpler and common way to handle it. ? Use ed. If you have line-numbers and variable names that's the easiest. Richard. thanks for any suggestions Shrey
Re: Symbolic replacement
On 9/14/05, shreyas krishnan [EMAIL PROTECTED] wrote: Hi, I am trying to find out whats the best way to do the following. I want to replace some pre-defined variables at a few pre-defined line with a new temperory variable. I guess the front-end should be the best place to do it. Do I need to do this for each rule in c-parse.y ? Is there a more simpler and common way to handle it. ? Use ed. If you have line-numbers and variable names that's the easiest. Or use perl, awk, etc. Also c-parse.y does not exist anymore. Thanks, Andrew Pinski
proposed Opengroup action for c99 command (XCU ERN 76)
I recently proposed to the Open Group an action that would modify the POSIX specification for the c99 command that is often implemented using GCC. I thought the action would not affect GCC's conformance, but Joseph S. Myers raised the issue of UCNs and multibyte characters and I'd like to double-check that GCC is OK. If the action does affect GCC I'd like to modify the action before it's too late. Here's the problem. Currently, POSIX places almost no requirements on how c99 transforms the physical source file into C source-language characters. For example, c99 is free to treat CR as LF, ignore trailing white space, convert tabs to spaces, or even (perversely) require that input files all start with line numbers that are otherwise ignored. This lack of specification was not intended, and I'm trying to help nail down the intent of what c99 is allowed to do. I proposed to insert the following paragraph after XCU page 213 line 8366 (i.e, at the end of the INPUT FILES section of the c99 spec http://www.opengroup.org/onlinepubs/009695399/utilities/c99.html): It is implementation-defined whether trailing white-space characters in each C-language source line are ignored. Otherwise, the multibyte characters of each source line are mapped on a one-to-one basis to the C source character set. In response Joseph S. Myers pointed out that this action would require c99 to use interpretation B of section 5.2.1 (page 20) of the C99 Rationale http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf. The Rationale says C preprocessors can be implemented in three ways: A. Convert everything to UCNs in basic source characters as soon as possible, that is, in translation phase 1. (This is what C++ requires, apparently.) B. Use native encodings where possible, UCNs otherwise. C. Convert everything to wide characters as soon as possible using an internal encoding that encompasses the entire source character set and all UCNs. The C99 standardizers chose (B), but said implementations could also use (A) or (C) because the C99 standard gives almost unlimited freedom in translation phase 1 for compilers to do whatever transformations they like. However, the proposed action for the c99 command would close this escape hatch, forcing interpretation (B) for c99 implementations. So my question is: Is it a burden on GCC to require interpretation (B)? My understanding is that GCC already uses (B), and that the answer is no, it's no problem, but if I'm wrong please let me know. For more details, please see Shell and Utilities Enhancement Request Number 76 (XCU ERN 76), which you can find in http://www.opengroup.org/austin/aardvark/latest/xcubug2.txt. Also please see the followup email discussion at http://www.opengroup.org/austin/mailarchives/ag/ (look for messages whose subject lines contain XCU ERN 76). Thanks.
Re: GCC 4.0.2 RC1 Available
Mark Mitchell wrote: It's important to test the actual tarballs, rather than CVS, to check for any packaging issues. If you can, download and build the tarballs, post test results to the gcc-testresults mailing list with and contrib/test_summary. If you encounter problems, please file them in bugzilla, and add me to the CC: list. s390(x)-ibm-linux are looking good: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00688.html http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00689.html Bye, Ulrich -- Dr. Ulrich Weigand Linux on zSeries Development [EMAIL PROTECTED]
Re: GCC 4.0.2 RC1 Available
On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote: Assuming that no critical problems emerge, I'll do the final release within the next week. Looks good on x86-linux and x86_64-linux for Ada: http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00691.html http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00690.html On x86_64 I get 4 unexpected failures for C: FAIL: gcc.dg/cpp/arith-3.c (test for bogus messages, line 257) FAIL: gcc.dg/setjmp-2.c (test for excess errors) WARNING: gcc.dg/setjmp-2.c compilation failed to produce executable FAIL: gcc.dg/short-compare-1.c (test for excess errors) WARNING: gcc.dg/short-compare-1.c compilation failed to produce executable FAIL: gcc.dg/short-compare-2.c (test for excess errors) On x86, one XPASS for C: XPASS: gcc.dg/vect/vect-22.c scan-tree-dump-times vectorized 3 loops 1 Laurent
Re: proposed Opengroup action for c99 command (XCU ERN 76)
On Wed, Sep 14, 2005 at 01:50:19PM -0700, Paul Eggert wrote: In response Joseph S. Myers pointed out that this action would require c99 to use interpretation B of section 5.2.1 (page 20) of the C99 Rationale http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf. The Rationale says C preprocessors can be implemented in three ways: A. Convert everything to UCNs in basic source characters as soon as possible, that is, in translation phase 1. (This is what C++ requires, apparently.) B. Use native encodings where possible, UCNs otherwise. C. Convert everything to wide characters as soon as possible using an internal encoding that encompasses the entire source character set and all UCNs. The C99 standardizers chose (B), but said implementations could also use (A) or (C) because the C99 standard gives almost unlimited freedom in translation phase 1 for compilers to do whatever transformations they like. However, the proposed action for the c99 command would close this escape hatch, forcing interpretation (B) for c99 implementations. So my question is: Is it a burden on GCC to require interpretation (B)? This is written in terms of internal implementation rather than visible behavior. Can you provide an example that lets us distinguish a compiler that uses method A, from a compiler that uses method B? If where possible in B simply means in cases where otherwise the user could tell that we aren't doing A, then there would be no observable difference.
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Paul Eggert wrote: So my question is: Is it a burden on GCC to require interpretation (B)? My understanding is that GCC already uses (B), and that the answer is no, it's no problem, but if I'm wrong please let me know. GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and any implementation of c99 that uses GCC would presumably also be non-conforming. Ross Ridge
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Ross Ridge wrote: GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and any implementation of c99 that uses GCC would presumably also be non-conforming. Robert Dewar wrote: What exactly is the observable non-conformance? GCC doesn't claim C99 conformance. The following URL lists a number of different areas in which GCC is known not to conform: http://gcc.gnu.org/c99status.html Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db //
Re: On which platforms is -fvisibility supported?
On Sep 14, 2005, at 8:59 AM, Jonathan Turkanis wrote: I've asked this question twice at gcc-help, but got no response. On which platforms is the -fvisibility option supported? autoconf will answer this question for you, please use it. Giving you an answer strikes me as dangerous. If you tell us what the real question is, maybe we can answer that one. ELF, darwin would be my approximate answer, if you had to have one. The GCC docs here (http://tinyurl.com/99wc8) suggest that it is a subset of ELF platforms. Is that correct? No. It also works on darwin, darwin is not an ELF platform.
Re: proposed Opengroup action for c99 command (XCU ERN 76)
[EMAIL PROTECTED] (Ross Ridge) writes: Ross Ridge wrote: GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and any implementation of c99 that uses GCC would presumably also be non-conforming. Robert Dewar wrote: What exactly is the observable non-conformance? GCC doesn't claim C99 conformance. The following URL lists a number of different areas in which GCC is known not to conform: http://gcc.gnu.org/c99status.html How does the fact that gcc does not currently conform to C99 imply that gcc doesn't use (A), (B), or (C)? In any case, the general goal is to conform to C99, so it still makes sense to discuss this. Ian
Tom Tromey as Java maintainer
The steering committee has agreed (as has Andrew Haley and Tom) that Tom Tromey should be added as a Java maintainer, in addition to libgcj maintainer. (About time, considering how much Java work Tom has done, including more and more compiler work.) Thanks for all the work you've done over the years! Tom, please add yourself to the MAINTAINERS file. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Paul Eggert wrote:- Here's the problem. Currently, POSIX places almost no requirements on how c99 transforms the physical source file into C source-language characters. For example, c99 is free to treat CR as LF, ignore trailing white space, convert tabs to spaces, or even (perversely) require that input files all start with line numbers that are otherwise ignored. This lack of specification was not intended, and I'm trying to help nail down the intent of what c99 is allowed to do. I suggest we simply remove the GCC extension. I never liked it, it's awkward to code, and it slows down CPP a bit. Neil.
Re: On which platforms is -fvisibility supported?
Mike Stump wrote: On Sep 14, 2005, at 8:59 AM, Jonathan Turkanis wrote: I've asked this question twice at gcc-help, but got no response. On which platforms is the -fvisibility option supported? autoconf will answer this question for you, please use it. Do you mean I should run autoconf on each platform where GCC is available to get an answer? I'm sure you don't think this is a practical suggestion, which leaves me wondering what you really mean. Giving you an answer strikes me as dangerous. Why? If you tell us what the real question is, maybe we can answer that one. First tell me what your real answer is. ELF, darwin would be my approximate answer, if you had to have one. You don't have to have one. But a non-answer is worse than no answer. The GCC docs here (http://tinyurl.com/99wc8) suggest that it is a subset of ELF platforms. Is that correct? No. It also works on darwin, darwin is not an ELF platform. Then the documentation is seriously misleading. -- Jonathan Turkanis www.kangaroologic.com
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Ross Ridge wrote: GCC doesn't use (A), (B) or (C). GCC doesn't conform to C99 and any implementation of c99 that uses GCC would presumably also be non-conforming. Robert Dewar wrote: What exactly is the observable non-conformance? Ross Ridge wrote: GCC doesn't claim C99 conformance. The following URL lists a number of different areas in which GCC is known not to conform: http://gcc.gnu.org/c99status.html Ian Lance Taylor wrote: How does the fact that gcc does not currently conform to C99 imply that gcc doesn't use (A), (B), or (C)? It doesn't, the implication is the other way around. But if you're asking for observable non-conformance then there are lot more obvious ways to observe it than by showing that GCC doesn't use (A), (B) or (C). In any case, the general goal is to conform to C99, so it still makes sense to discuss this. Maybe, but there's no implementation of (A) or (C) in GCC that would make requiring (B) a burden. So I think Paul Eggert's question has been answered. Ross Ridge
checksum files not ^C safe
These types of rules are not ^C safe: cc1-checksum.c : cc1-dummy$(exeext) build/genchecksum$(build_exeext) build/genchecksum$(build_exeext) cc1-dummy$(exeext) $@ It is a general property that builds are ^C safe, the above changes retard that feature. If you output to a temp file, and then mv them to the final file, they will be (I think) safe.
Re: PING [4.1 regression, patch] build i686-pc-mingw32
On Mon, Jul 25, 2005 at 05:33:19PM -0400, Christopher Faylor wrote: On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote: Maybe one solution would be to patch pex-win32 for mingw so that it could understand '#!' style shell scripts? That would at least allow bootstrapping. That would be wonderful, and that's exactly the right place to put it too. I'm assuming I can persuade one of you to do that? ;-) I'm going to define pex-win32.c as being within the realm of the mingw maintainership (if you hadn't assumed that already). I'd be happy to implement this. I'd like to get Danny's opinion on this first, though, in case I missed something. With DJ's (private) approval, I've checked in a fix to implement this. Sorry for the long delay. cgf
Re: [gelato-gcc] Re: Introduction of GCC improvement work for Itanium via Gelato Federation
There were many good ideas and suggestions in the email thread. Speeding up GCC performance with community effort is the ultimate path for Itanium. HP is committed to work with the GCC community to make this happen. I also agree with the observation that we need an intermediate path to beef up the performance on Itanium in order to keep its competitiveness. Regards, Shin-Ming Liu Wen-mei W. Hwu wrote: I agree with Vladimir wholeheartedly. After working on OpenIMPACT for years, I reached the conclusion that the ONLY way to make a real difference for Linux Itanium users is to help improve the mainstream GCC compiler. That is why my team (esp. Bob Kidd) is actively helping with a strong superblock path in GCC. As you know, the superblock techniques originated in IMPACT more than 12 years ago. We will be glad to work with the community to improve other aspects of the the GCC (interprocedural pointer analysis, array dependence, memory dataflow, etc.) based on our experience with IMPACT in the future. I personally see OpenIMPACT as proving ground for techniques and GCC as the real delivery vehicle for the software base. Regards, wen-mei At 08:49 AM 9/14/2005, Vladimir Makarov wrote: Steven Bosscher wrote: On Wednesday 14 September 2005 10:53, Robert Dewar wrote: Gerald Pfeifer wrote: (If so, I'm wondering what it's going to buy the interested parties, because I have a hard time seeing one of the large GNU/Linux distributors switching to a compiler different from FSF GCC for Itanium.) Surely this depends on relative performance ... My guess is that there are more important things than performance, such as stability, community support, maintenance burden, etc. I would add single compiler for other linux (and non-linux) ports, more compact code for Itanium (sometimes 2 times more compact), many additional features (last ones are mudflap and stack protector). If it was perfomance only, people would have switched to Intel, ORC or Openimpact compilers long ago. But according Gelato poll, most of Itanium users (like 70%) prefer to use gcc than other compilers. ___ Gelato-gcc mailing list [EMAIL PROTECTED] https://www.gelato.unsw.edu.au/mailman/listinfo/gelato-gcc ___ Gelato-gcc mailing list [EMAIL PROTECTED] https://www.gelato.unsw.edu.au/mailman/listinfo/gelato-gcc
RFA: pervasive SSE codegen inefficiency
Consider the following SSE code
(-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2)
#include xmmintrin.h
__m128i foo3(__m128i z, __m128i a, int N) {
int i;
for (i=0; iN; i++) {
a = _mm_add_epi64(z, a);
}
return _mm_add_epi64(a, a);
}
__m128i foo1(__m128i z, __m128i a, int N) {
int i;
for (i=0; iN; i++) {
a = _mm_add_epi16(z, a);
}
return _mm_add_epi16(a, a);
}
The first inner loop compiles to
paddq %xmm0, %xmm1
Good. The second compiles to
movdqa %xmm2, %xmm0
paddw %xmm1, %xmm0
movdqa %xmm0, %xmm1
when it could be using a single paddw. The basic problem is that
our approach defines __m128i to be V2DI even though all the operations
on the object are V4SI, so there are a lot of subreg's that don't need
to generate code. I'd like to fix this, but am not sure how to go
about it.
The pattern-matching and RTL optimizers seem quite hostile to mismatched
mode operations. If I were starting from scratch I'd define a single
V128I mode
and distinguish paddw and paddq by operation codes, or possibly by using
subreg:SSEMODEI throughout the patterns. Any less intrusive ideas?
Thanks.
(ISTR some earlier discussion about this but can't find it; apologies if
I'm reopening something that shouldn't be:)
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Ross Ridge wrote: GCC doesn't claim C99 conformance. The following URL lists a number of different areas in which GCC is known not to conform: I was not asking the general question, I was asking how it fails to conform wrt the particular technical issue at hand.
where is the floatsidf?
Hi, Still software floating point. : Thanks for the help. Now I use soft-float to build libgcc, but _floatdidf.o fails for Cannot branch to undefined symbol, __floatsidf. Should I define floatsidf in md file? But I have no floating point registers. Regards. Eric
Re: where is the floatsidf?
Eric Fisher [EMAIL PROTECTED] writes: Thanks for the help. Now I use soft-float to build libgcc, but _floatdidf.o fails for Cannot branch to undefined symbol, __floatsidf. Should I define floatsidf in md file? But I have no floating point registers. __floatsidf should be defined by _si_to_df.o which is compiled from fp-bit.c. Ian
where is the floatsidf?
Thank you very much about the help. Acctually, I have included fp-bit.c in libgcc.mk. But the order is not right, I think. Because _si_to_df.o is after the _floatdidf.o. Also, how to change _si_to_df.o to _floatsidf.o? In md file? I'm wondering that maybe I needn't to implement libgcc2.a, but that makes gcc fail to build. Eric
Re: RFA: pervasive SSE codegen inefficiency
On Sep 14, 2005, at 9:21 PM, Dale Johannesen wrote:
Consider the following SSE code
(-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2)
4256776a.c
The first inner loop compiles to
paddq %xmm0, %xmm1
Good. The second compiles to
movdqa %xmm2, %xmm0
paddw %xmm1, %xmm0
movdqa %xmm0, %xmm1
when it could be using a single paddw. The basic problem is that
our approach defines __m128i to be V2DI even though all the operations
on the object are V4SI, so there are a lot of subreg's that don't need
to generate code. I'd like to fix this, but am not sure how to go
about it.
From real looks of this looks more like a register allocation issue and
nothing to do with subregs at all, except subregs being there.
Take a look at .greg:
;; 4 regs to allocate: 64 (4) 61 63 (4) 65
;; 61 conflicts: 61 63 64 65 66 7 21
;; 63 conflicts: 61 63 64 65 66 7 21 22
;; 64 conflicts: 61 63 64 65 7
;; 64 preferences: 21 22
;; 65 conflicts: 61 63 64 65 66 7 21
;; 66 conflicts: 61 63 65 66 7 21
;; 66 preferences: 22
;; 67 conflicts: 67 7 21
;; 67 preferences: 22
and then look at allocation:
(reg:V8HI 21 xmm0 [66])
(reg:V8HI 22 xmm1 [orig:64 a ] [64])
(reg/v:V2DI 23 xmm2 [orig:63 z ] [63])
Original instructions:
(insn:HI 23 21 25 2 (set (reg:V8HI 66)
(plus:V8HI (subreg:V8HI (reg/v:V2DI 63 [ z ]) 0)
(subreg:V8HI (reg/v:V2DI 64 [ a ]) 0))) 680 {*addv8hi3}
(nil)
(expr_list:REG_DEAD (reg/v:V2DI 64 [ a ])
(nil)))
(insn:HI 25 23 27 2 (set (reg/v:V2DI 64 [ a ])
(subreg:V2DI (reg:V8HI 66) 0)) 542 {*movv2di_internal}
(insn_list:REG_DEP_TRUE 23 (nil))
(expr_list:REG_DEAD (reg:V8HI 66)
(nil)))
(insn:HI 33 31 38 3 (set (reg:V8HI 67)
(plus:V8HI (subreg:V8HI (reg/v:V2DI 64 [ a ]) 0)
(subreg:V8HI (reg/v:V2DI 64 [ a ]) 0))) 680 {*addv8hi3}
(nil)
(expr_list:REG_DEAD (reg/v:V2DI 64 [ a ])
(nil)))
(note:HI 38 33 41 3 NOTE_INSN_FUNCTION_END)
(insn:HI 41 38 47 3 (set (reg/i:V2DI 21 xmm0 [ result ])
(subreg:V2DI (reg:V8HI 67) 0)) 542 {*movv2di_internal}
(insn_list:REG_DEP_TRUE 33 (nil))
(expr_list:REG_DEAD (reg:V8HI 67)
(nil)))
Instructions after allocation:
(insn 60 21 23 2 (set (reg:V8HI 21 xmm0 [66])
(reg:V8HI 23 xmm2)) 540 {*movv8hi_internal} (nil)
(nil))
(insn:HI 23 60 25 2 (set (reg:V8HI 21 xmm0 [66])
(plus:V8HI (reg:V8HI 21 xmm0 [66])
(reg:V8HI 22 xmm1 [orig:64 a ] [64]))) 680 {*addv8hi3} (nil)
(nil))
(insn:HI 25 23 27 2 (set (reg/v:V2DI 22 xmm1 [orig:64 a ] [64])
(reg:V2DI 21 xmm0 [66])) 542 {*movv2di_internal}
(insn_list:REG_DEP_TRUE 23 (nil))
(nil))
...
(insn 61 31 33 3 (set (reg:V8HI 21 xmm0 [67])
(reg:V8HI 22 xmm1)) 540 {*movv8hi_internal} (nil)
(nil))
(insn:HI 33 61 38 3 (set (reg:V8HI 21 xmm0 [67])
(plus:V8HI (reg:V8HI 21 xmm0 [67])
(reg:V8HI 22 xmm1 [orig:64 a ] [64]))) 680 {*addv8hi3} (nil)
(nil))
(note:HI 38 33 41 3 NOTE_INSN_FUNCTION_END)
(insn:HI 41 38 47 3 (set (reg/i:V2DI 21 xmm0 [ result ])
(reg:V2DI 21 xmm0 [67])) 542 {*movv2di_internal}
(insn_list:REG_DEP_TRUE 33 (nil))
(nil))
If we allocated 64 and 63 as the same register, it would have worked
correctly.
Yes removing the extra set helps but does not solve the real issue of
the
register allocator being stupid.
Thanks,
Andrew Pinski
Re: proposed Opengroup action for c99 command (XCU ERN 76)
I was not asking the general question, I was asking how it fails to conform wrt the particular technical issue at hand. Since GCC doesn't have any code that does (A), (B), or (C) it doesn't place a burden on GCC to require it to do (B). That's sufficient to answer the techinical issue at hand. While that implies GCC doesn't conform, I said so explictly because Paul Eggert said that c99 is often implemented using GCC. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/u/rridge/ db //
Re: where is the floatsidf?
Eric Fisher [EMAIL PROTECTED] writes: Acctually, I have included fp-bit.c in libgcc.mk. But the order is not right, I think. Because _si_to_df.o is after the _floatdidf.o. Also, how to change _si_to_df.o to _floatsidf.o? In md file? The order of the objects in the libgcc.a archive does not matter. All that matters is that all the symbols are defined in the archive, and that you link against it (which should happen automatically). The name of the object within the archive does not matter. All that matters is the symbols defined within the archive. You can see the symbols by using the nm program. Ian
Re: proposed Opengroup action for c99 command (XCU ERN 76)
[EMAIL PROTECTED] (Ross Ridge) writes: I was not asking the general question, I was asking how it fails to conform wrt the particular technical issue at hand. Since GCC doesn't have any code that does (A), (B), or (C) it doesn't place a burden on GCC to require it to do (B). That's sufficient to answer the techinical issue at hand. While that implies GCC doesn't conform, I said so explictly because Paul Eggert said that c99 is often implemented using GCC. I am the opposite of an expert on this topic. But in fact gcc does appear to have code related to (A), (B), and (C). I repeat those choices here from Paul's original e-mail: A. Convert everything to UCNs in basic source characters as soon as possible, that is, in translation phase 1. (This is what C++ requires, apparently.) B. Use native encodings where possible, UCNs otherwise. C. Convert everything to wide characters as soon as possible using an internal encoding that encompasses the entire source character set and all UCNs. Now, see libcpp/charset.c. See the -finput-charset= option. To me that looks like code which does something related to (A), (B), or (C). Ian
Re: proposed Opengroup action for c99 command (XCU ERN 76)
I am the opposite of an expert on this topic. But in fact gcc does appear to have code related to (A), (B), and (C). I repeat those choices here from Paul's original e-mail: A. Convert everything to UCNs in basic source characters as soon as possible, that is, in translation phase 1. (This is what C++ requires, apparently.) B. Use native encodings where possible, UCNs otherwise. C. Convert everything to wide characters as soon as possible using an internal encoding that encompasses the entire source character set and all UCNs. Now, see libcpp/charset.c. See the -finput-charset= option. To me that looks like code which does something related to (A), (B), or (C). It does. I think the best bet would be (A) for the code that we have in libcpp at the moment. Right now we translate upon getting characters into an intermediate format that does encompass as much as possible (IIRC). That, and it'd make sure that we handle what c++ requires. I'm also not as much of an expert as I'd have liked to be when dealing with this in the first place. -eric
Re: GCC 4.0.2 RC1 Available
Laurent GUERBY wrote: On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote: Assuming that no critical problems emerge, I'll do the final release within the next week. Libgcj seems broken with --enable-java-awt=gtk,xlib --enable-gtk-cairo. (on darwin ppc and linux ppc at least, but I guess on all others too who uses the above config switches) Try to come up with a patch to fix the build. Andreas
[Bug c/10719] invalid code generated (x86, int $5) with __builtin_va_arg(va, char);
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-14 06:15 --- I still say generating code that is not executable is a ridiculous way to handle this ambiguity in the standard... You still don't get the point. Read again comment #2, the bottom line is that it's the best code the compiler can generate portably. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug c/10719] invalid code generated (x86, int $5) with __builtin_va_arg(va, char);
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 06:25 --- as promoted according to the default argument promotions is what makes this undefined by the way. char is promoted to int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug fortran/17740] ICE in gfc_trans_arrayfunc_assign, at fortran/trans-expr.c:2011
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-14 06:31 --- Fixed on mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17740
[Bug middle-end/23125] [4.0/4.1 Regression] OpenBSD's zic.c causes g++ but not gcc to segfault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 06:31 --- I Have a fix which I will posting in the morning. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23125
[Bug c++/23372] [4.0/4.1 Regression] Temporary aggregate copy not elided when passing parameters by value
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 06:36 --- Another way to fix this would have copy-propagation for aggregates, see PR 14295. -- What|Removed |Added BugsThisDependsOn||14295 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
[Bug target/18562] SSE constant vector initialization produces dead constant values on stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14
06:51 ---
Hmm, but vectors are not consider as aggregates.
at the tree level right before optimization, we have:
A_6 = {1.299523162841796875e+0, 1.299523162841796875e+0,
1.299523162841796875e+0, 1.299523162841796875e+0};
# result_26 = V_MAY_DEF result_14;
__builtin_ia32_storeups (result, A_6);
I would have thought that VECTOR_CST would be considered a constant and
propgrated into
__builtin_ia32_storeups and that we would have folded __builtin_ia32_storeups
at the tree level.
So I think there are two issues now, the first is that we don't constant prop
VECTOR_CST (if this is truely
a VECTOR_CST in store_ccp):
A_6 = {1.299523162841796875e+0, 1.299523162841796875e+0,
1.299523162841796875e+0, 1.299523162841796875e+0};
Lattice value changed to VARYING. Adding SSA edges to worklist.
And then we need a fold specific to x86 for __builtin_ia32_storeups, after that
it should just work.
--
What|Removed |Added
BugsThisDependsOn|14295 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
[Bug target/18562] SSE constant vector initialization produces dead constant values on stack
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 07:09 --- Actually the issue is that we don't change the constructor into a VECTOR_CST: constructor 0x41ec8720 type vector_type 0x41ebb9a0 __v4sf type real_type 0x41e0fd90 float sizes-gimplified BLK size integer_cst 0x41e11a60 128 unit size integer_cst 0x41e11a80 16 align 128 symtab 0 alias set -1 nunits 4 which we should in this case. And this happens in DOM or in CCP with replacing _mm_set1_ps with _mm_set1_ps (which really are implemented the same way). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18562
[Bug tree-optimization/18463] [4.0 Regression] suboptimal use of fancy x86 addressing modes
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-14 08:21 --- (From update of attachment 7541) Already in mainline -- What|Removed |Added Attachment #7541 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
[Bug middle-end/22480] [4.1 Regression] ICE in convert_move, at expr.c:390 with -ftree-vectorize
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-14 09:27 --- Subject: Bug 22480 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-14 09:27:02 Modified files: gcc: ChangeLog Makefile.in tree-vect-transform.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg/vect: pr22480.c Log message: 2005-09-14 Uros Bizjak [EMAIL PROTECTED] PR middle-end/22480 * tree-vect-transform.c (vectorizable_operation): Return false for scalar shift operations and for vector shift operations with non-invariant shift arguments. Use scalar tree operand op1 as a shift operand when vector shift insn pattern uses scalar shift operand. * Makefile.in (tree-vect-transform.o): Depend on recog.h. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9953r2=2.9954 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gccr1=1.1540r2=1.1541 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vect-transform.c.diff?cvsroot=gccr1=2.43r2=2.44 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.6063r2=1.6064 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/vect/pr22480.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22480
[Bug tree-optimization/18463] [4.0 Regression] suboptimal use of fancy x86 addressing modes
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-09-14 11:04 --- Auch; that patch is actually a very bad idea. Pretending that complex addressing modes are cheaper, when they are not, is just confusing. If there are optimizers that indeed want to prefer complex addressing modes (like cse and combine, I suppose), they should reflect that in the cost function they are using, rather than forcing this missconception to every other optimizer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
[Bug tree-optimization/18463] [4.0 Regression] suboptimal use of fancy x86 addressing modes
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-14 12:22 --- It looks like it is just following existing practice? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
[Bug middle-end/23411] [data deps] Distance on outer loops for self output deps
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr 2005-09-14 12:38 --- Subject: Re: [data deps] Distance on outer loops for self output deps In this case neither implementation got the dependece right: there are bugs in both implementations. For the following nested loop: loop_1 loop_2 A[5] = ... end_loop_2 end_loop_1 BAD would answer: (1, 1), that would mean that for getting the same access we'd have to run loop_1 once *and* loop_2 once: this is false. BOP would answer: (0, 0), that would mean that neither loop_1 nor loop_2 carry dependences, in other words, both loops are parallel: this is false. The right answer is a set of distance vectors: (0, 1) and (1, 0). For getting to the same element in the array we have to run loop_1 once *or* loop_2 has to run once. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23411
[Bug tree-optimization/18463] [4.0 Regression] suboptimal use of fancy x86 addressing modes
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-09-14 12:41 --- Subject: Re: [4.0 Regression] suboptimal use of fancy x86 addressing modes It looks like it is just following existing practice? yes, I know. The practice is just wrong, though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18463
[Bug c++/23840] [3.4/4.0/4.1 Regression] Bogus invalid lvalue in unary '' diagnostic and ICE with va_arg
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-14 13:41 --- Which also hints at the problem why we don't accept this. The instance from which we take the qualifiers is VA_ARG_EXPR apD.1742 and we do not handle this in build_this / build_address / build_unary_op. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23840
[Bug awt/16203] need to kill awt helper threads on gui app exit
--- Additional Comments From fitzsim at redhat dot com 2005-09-14 13:52 --- This broke when we moved back to the two-threaded event loop model. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16203
[Bug awt/16203] need to kill awt helper threads on gui app exit
--- Additional Comments From fitzsim at redhat dot com 2005-09-14 13:53 --- *** Bug 23877 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||roman at kennke dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16203
[Bug c++/23840] [3.4/4.0/4.1 Regression] Bogus invalid lvalue in unary '' diagnostic and ICE with va_arg
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-14 13:54 --- I have a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-09-12 20:15:48 |2005-09-14 13:54:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23840
[Bug rtl-optimization/23870] [3.4 regression] loop-unswitching hangs compiler (and whole computer!)
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-09-14 13:56 --- Confirmed. This seems to be a problem with loop unswitching -- What|Removed |Added Status|UNCONFIRMED |NEW Component|other |rtl-optimization Ever Confirmed||1 Known to fail||3.4.5 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-09-14 13:56:50 date|| Summary|continue hangs compiler (and|[3.4 regression] loop- |whole computer!)|unswitching hangs compiler ||(and whole computer!) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23870
[Bug c++/23799] [4.1 regression] ICE: no-op convert from 8 to 4 bytes in initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 14:32 --- Note the testcase is now called struct3.C. Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-09-14 14:32:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23799
[Bug rtl-optimization/23870] [3.4 regression] loop-unswitching hangs compiler (and whole computer!)
-- What|Removed |Added Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23870
[Bug libfortran/21468] vectorizing libfortran
-- Bug 21468 depends on bug 22480, which changed state. Bug 22480 Summary: [4.1 Regression] ICE in convert_move, at expr.c:390 with -ftree-vectorize http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22480 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21468
[Bug middle-end/22480] [4.1 Regression] ICE in convert_move, at expr.c:390 with -ftree-vectorize
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 14:46 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22480
[Bug c++/23749] Bad diagnostic
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:23
---
This has been complained about in other PRs before. The problem is that
the following syntax is allowed:
struct S {} typedef A;
i.e., the infix-form of typedef. Since there are other PRs about this,
I close this one. (I am forced to mark it as INVALID, though, clearly, it
is not.)
W.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23749
[Bug c++/22632] GCC won't produce assignment operator warnings
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:25 --- I don't see the problem either. You should simply mark the argument to the constructor as const so that temporaries can be bound to it. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22632
[Bug c++/23211] [3.4/4.0/4.1 regression] using dec in nested class doesn't import name
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:28 --- Confirmed. This is a regression against 3.3 which compiled the code just fine. W. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||rejects-valid Known to fail||3.4.5 4.0.2 4.1.0 Known to work||3.3.4 Last reconfirmed|-00-00 00:00:00 |2005-09-14 15:28:35 date|| Summary|using dec in nested class |[3.4/4.0/4.1 regression] |doesn't import name |using dec in nested class ||doesn't import name Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug c++/23211] [3.4/4.0/4.1 regression] using dec in nested class doesn't import name
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 15:34 --- As I said, I think this is a dup of bug 14258, we never really got using correct. -- What|Removed |Added BugsThisDependsOn||14258 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug c++/23227] SFINAE bug
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:35 --- I believe the compiler is correct. In order to check whether there is a conversion sequence from float to AC, it needs to instantiate the type, parts of which are declared by incomplete. This should be an error. icc says the same, whatever this means. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug c++/23510] Confusing output for improperly terminated template structures
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:36 --- Indeed a duplicate. *** This bug has been marked as a duplicate of 9335 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23510
[Bug c++/9335] Inordinately long output when maximum template depth is exceeded
--- Additional Comments From bangerth at dealii dot org 2005-09-14 15:36 --- *** Bug 23510 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||tron dot thomas at verizon ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug fortran/19358] [gfortran] Segfault with missing upper bound
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-14 15:42 --- Fixed in 4.0.2. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19358
[Bug fortran/15502] [meta-bug] bugs needed for SPEC CPU 2K and 2K5/6 and 95
-- Bug 15502 depends on bug 19358, which changed state. Bug 19358 Summary: [gfortran] Segfault with missing upper bound http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19358 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15502
[Bug c++/23211] [3.4/4.0/4.1 regression] using dec in nested class doesn't import name
-- What|Removed |Added Target Milestone|4.0.3 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
[Bug c/10719] invalid code generated (x86, int $5) with __builtin_va_arg(va, char);
--- Additional Comments From appfault at hotmail dot com 2005-09-14 16:09 --- Ok, so that's the best code it can generate, fine. So if instant segfault is the best possible generated code, I think NOT generating any code is far more helpful to the user. If not generating any code doesn't conform to the standard, then it seems like it should be at least optional. Who knows how many of these int $5 ticking timebombs are lurking out there in mission critical software. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug c/10719] invalid code generated (x86, int $5) with __builtin_va_arg(va, char);
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-14 16:23 --- Ok, so that's the best code it can generate, fine. So if instant segfault is the best possible generated code, I think NOT generating any code is far more helpful to the user. If not generating any code doesn't conform to the standard, then it seems like it should be at least optional. -Werror precisely exists for that purpose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10719
[Bug tree-optimization/23853] [4.1 regression] ICE: in tree_low_cst, at tree.c:4270
--- Additional Comments From micis at gmx dot de 2005-09-14 17:23 --- I did a bootstrap with C/C++, ran the testsuite and got no new regressions for your patch. Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23853
