Re: ISO C++ forbids initialization in array new?
WU Yongwei wrote: > Well, I see this in the gcc error message. Can someone here kindly > point to me which part of the Standard specified this behaviour? I > thought it should be in 5.3.4, but was not able to find the words > there. It might be better if the error message said "non-default initialization" since default initialization is allowed (and required). I assume you are trying something like this: int* i = new int[5](23); A new initializer must have the form (...) (see 5.3.4/1) and the only way that can be used to initialize an array is for default construction. This is OK, and default initialises the array, which default initialises each element (8.5/5) int* i = new int[5](); but this is not OK: int* i = new int[5](23); because it is not valid to initialise an array like this: typedef int (five_ints)[5]; five_ints i(23); this gives: array_init.cc:8: error: cannot initialize arrays using this syntax HTH jon -- sigfault
Re: ISO C++ forbids initialization in array new?
Jonathan Wakely wrote: > WU Yongwei wrote: > > > Well, I see this in the gcc error message. Can someone here kindly > > point to me which part of the Standard specified this behaviour? I > > thought it should be in 5.3.4, but was not able to find the words > > there. > > It might be better if the error message said "non-default > initialization" since default initialization is allowed (and required). Oops! that was meant to say "required for some types" (e.g. const-qualified types, non-POD types) Too early in the morning for me to be answering questions like this! jon
Re: ISO C++ forbids initialization in array new?
WU Yongwei wrote: > Well, I see this in the gcc error message. Can someone here kindly > point to me which part of the Standard specified this behaviour? I > thought it should be in 5.3.4, but was not able to find the words > there. > > By the way, anyone knows the rationale of this behaviour? It is not explicitly forbidden. Rather, there is no syntax defined that would enable it (so it is implicitly forbidden) you might be interested in the following paper from the last ISO mailing ;¬) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1824.htm AlisdairM
Re: [PATCH]: Proof-of-concept for dynamic format checking
On 2005-08-18 17:53:24 -0700, Joe Buck wrote:
> On Thu, Aug 18, 2005 at 11:52:36PM +0200, Vincent Lefevre wrote:
> > On 2005-08-18 21:53:47 +0200, Branko Čibej wrote:
> > > Mike Stump wrote:
> > [...]
> > > > printf ("%d", i);
> > [...]
> > > Now imagine that the output of the original program depends on the
> > > locale that's in force at execution time, which defines numberic
> > > output to be in arabic numerals (real ones, not the sort we see in
> > > ASCII).
> >
> > Is it possible? I would have thought that only the decimal-point
> > character depends on the locale.
>
> The digits we use come from the Arabs, and look much the same in Arabic.
> Check an Arabic-language site, for example http://www.aljazeera.net/ .
I agree, but you don't answer the question. The point is that they
are different characters. I think the digits mentioned by Branko
are the characters U+0660 to U+0669 (ARABIC-INDIC DIGIT ZERO and
so on). Many languages have their own 0 to 9 digits in Unicode.
But I don't think the decimal digits used for %d above depend on
the locale (e.g. I don't think a C implementation may use them if
it uses the ASCII ones in the C locale).
--
Vincent Lefèvre <[EMAIL PROTECTED]> - Web:
gcc-4.1-20050819 is now available
Snapshot gcc-4.1-20050819 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050819/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-08-19 10:43 UTC You'll find: gcc-4.1-20050819.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050819.tar.bz2 C front end and core compiler gcc-ada-4.1-20050819.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050819.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050819.tar.bz2 C++ front end and runtime gcc-java-4.1-20050819.tar.bz2 Java front end and runtime gcc-objc-4.1-20050819.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050819.tar.bz2The GCC testsuite Diffs from 4.1-20050813 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.
Re: Keyword _Imaginary in C99 standard and in GCC
On Fri, 19 Aug 2005, Yao qi wrote: > Hi, everyone, > I have looked through C99 standard, in 6.4.1 Keywords, "_Imaginary" is > mentioned as a keyword in this standard. However, it seems that GCC can not > recognize it, report error: '_Imaginary' undeclared. I also search it in GCC > info, there is no spot mentioned that. Maybe GCC does not include it as a > keyword, I am not sure about that, am I missing something? Maybe someone of > you could clarify for me. Thanks in advance. What use do you have for a keyword which is reserved but cannot be used anywhere? As of TC2, _Imaginary is just that; it is not a type specifier, and an implementation implementing Annex G (which is not normative) is incompatible with the normative parts of the standard (at least as regards the header definition of "I" having conflicting definitions in the standard and in Annex G). There are serious doubts (as discussed on the WG14 reflector in the past) about the utility of imaginary types as defined in Annex G. Now, adding _Imaginary as a keyword which is not permitted anywhere in the syntax (so you get parse errors and can't e.g. declare variables called _Imaginary) would be a trivial patch, but not clearly a very useful one. -- Joseph S. Myers [EMAIL PROTECTED]
gcc successful builds on aix 5.3 ml 2
Full gcc 4.0.1 distribution used for source tree. Hardware: IBM 9113-550 power5 4-way bash-2.05b$ /builds/gcc-4.0.1/config.guess powerpc-ibm-aix5.3.0.0 bash-2.05b$ oslevel -r 5300-02 bash-2.05b$ gcc -v Using built-in specs. Target: powerpc-ibm-aix5.3.0.0 Configured with: ../gcc-4.0.1/configure -v --disable-nls --enable-languages=c,c++,objc Thread model: aix gcc version 4.0.1 Second server, somewhat older hardware Hardware: IBM 7017-S80 6-way bash-2.03$ /usr/local/gcc-4.0.1/config.guess powerpc-ibm-aix5.3.0.0 bash-2.03$ which gcc /usr/local/bin/gcc bash-2.03$ gcc -v Using built-in specs. Target: powerpc-ibm-aix5.3.0.0 Configured with: /usr/local/gcc-4.0.1/configure -v --disable-nls --enable-languages=c,c++,objc --enable-threads=aix Thread model: aix gcc version 4.0.1 bash-2.03$ oslevel -r 5300-02
Question of pipeline description
I'm porting GCC 4.0.2 to a new VLIW architecture. There are 10 functions units (2 RISCs and 8 DSPs) in the architecture. The pipeline stages are: IS, ID(fetch operand), E1(ALU), E2, E3, E4(write back to register) For the circuit area reason, the pipeline forwarding mechanism is not available across two different function units. For example, the two instructions can use pipeline forwarding in order to reduce the stall cycles: add.r0r2, r3, r4@ the result is generated at the E1 stage nop.r0 @ stall 1 cycle add.r0r5, r6, r2@ E1 can forward to ID because the two instructions use the same function unit The two instructions cannot use the pipeline forwarding because they used difference function units (.r0 means that the instruction uses RISC0, and .r1 means that the instruction uses RISC1): add.r0r2, r3, r4@ write back to register at the E4 stage nop.r0 @ stall 1 cycle nop.r0 @ stall 1 cycle nop.r0 @ stall 1 cycle add.r1r5, r6, r2@ no forwarding mechanism between two different function units The pipeline description can write the following definition trivially: (define_query_cpu_unit "r0, r1, d0, d1, d2, d3, d4, d5, d6, d7") (define_insn_reservation "risc_data_processing" 4 (and (eq_attr "type" "dp") (eq_attr "fu" "risc")) "(r0 | r1)") I set the lantency time to 4 for general cases (without pipeline forwarding). And then I set a bypass rule for the pipeline forwading case: (define_bypass 1 "risc_data_processing" "risc_data_processing, risc_load_word, ...") It's only correct if the two RISC insns reserved the same RISC function unit. If the two insns reserved RISC0 and RISC1 respectively, the bypass rule is not suitable. I know that we can use the "guard function" in the (define_bypass ...), but it seems to no help for the situation. The "guard function" cannot know what function units the two insns reserved. Are there any other solutions for the situation? Thanks a lot.
Re: ISO C++ forbids initialization in array new?
On Fri, Aug 19, 2005 at 09:19:55AM +0100, Jonathan Wakely wrote: > WU Yongwei wrote: > > > Well, I see this in the gcc error message. Can someone here kindly > > point to me which part of the Standard specified this behaviour? I > > thought it should be in 5.3.4, but was not able to find the words > > there. > > It might be better if the error message said "non-default > initialization" since default initialization is allowed (and required). > > I assume you are trying something like this: > > int* i = new int[5](23); While this is not gcc-help, maybe we could make a FAQ item for this. For people who want to do something like this, I suggest std::vector i(5, 23); If the reason vector wasn't used in the first place was because some API needs an array, then use std::vector vector_i(5, 23); int* i = &*vector.begin(); The reason for the &* is to convert the vector iterator into a pointer to the first element.
Re: ISO C++ forbids initialization in array new?
Joe Buck <[EMAIL PROTECTED]> writes: > On Fri, Aug 19, 2005 at 09:19:55AM +0100, Jonathan Wakely wrote: >> I assume you are trying something like this: >> >> int* i = new int[5](23); > > While this is not gcc-help, maybe we could make a FAQ item for this. > For people who want to do something like this, I suggest > > std::vector i(5, 23); > > If the reason vector wasn't used in the first place was because some > API needs an array, then use > > std::vector vector_i(5, 23); > int* i = &*vector.begin(); This is not quite the same, because when vector_i goes out of scope it will be destructed, so you can't use the pointer beyond that point. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [PATCH]: Proof-of-concept for dynamic format checking
> "Ian" == Ian Lance Taylor writes: Ian> To make this kind of thing useful, I see two paths that we can follow. Ian> The second approach is of course to write a little language which is Ian> powerful enough to describe printf. The state machine language I Ian> described earlier is too simple and perhaps overly cryptic. If we're doing that, why not use an already existing little language? Then we have one less thing to maintain, document, and extend (since you know there will be a need for extensions). Of course this leads into the morass of picking a language. Folks, please resist the urge... you know what I mean. The idea of letting gcc load a .so to do the checking also seems fine. At least then the checking language is a standard one, not one we made up. I guess an intermediate approach would be to use that bytecode back end I heard you're hacking on. Tom
Internal Behavior of G++
Hi all, I am developing an intermediate compile using EDG C++ frontend. When I try to compile any c++ source file with my compiler it returns many errors.. like James:~/C_PP/test> C_CC -I/usr/include/c++/3.3 -I/usr/include/c++/3.3/i486-linux-gnu -I/usr/include -c helloworld.cpp "/usr/include/c++/3.3/i486-linux-gnu/bits/c++locale.h", line 39: warning: unrecognized #pragma #pragma GCC system_header ^ "/usr/include/locale.h", line 29: catastrophic error: could not open source file "stddef.h" #include ^ 1 catastrophic error detected in the compilation of "helloworld.cpp". Compilation terminated. C_CC --with-preincludes -D__linux__ -I/usr/include/c++/3.3 -I/usr/include/c++/3.3 -I/usr/include/c++/3.3/i486-linux-gnu -I/usr/include -o helloworld.o helloworld.cpp cafeCC: Error from subprocess: cafe++ "/usr/include/locale.h", line 29: error: could not open source file "stddef.h" #include ^ "/usr/include/iconv.h", line 24: error: could not open source file "stddef.h" #include ^ "/usr/include/bits/types.h", line 31: error: could not open source file "stddef.h" #include ^ 15 errors detected in the compilation of "helloworld.cpp". Compilation terminated. /**/ Now Can anyone guide me that how g(++/cc) starts its preprocessing and what macros it uses by default if there are no user defined.. Any suggestion will be appreciated.. Thanks. Raza Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: Internal Behavior of G++
On Fri, Aug 19, 2005 at 01:27:56PM -0700, Aoun Raza wrote: > I am developing an intermediate compile using EDG C++ > frontend. Then you are on the wrong list.
Re: Internal Behavior of G++
I have developed it already, but I want to use GCC headers.. and I see the problems described earlier --- Joe Buck <[EMAIL PROTECTED]> wrote: > On Fri, Aug 19, 2005 at 01:27:56PM -0700, Aoun Raza > wrote: > > I am developing an intermediate compile using EDG > C++ > > frontend. > > Then you are on the wrong list. > Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Re: Internal Behavior of G++
On Friday, August 19, 2005, at 01:57 PM, Aoun Raza wrote: I have developed it already, but I want to use GCC headers.. and I see the problems described earlier Must be a bug in your compiler, because g++ compiles it just fine, go ask them.
Re: [PATCH]: Proof-of-concept for dynamic format checking
Tom Tromey <[EMAIL PROTECTED]> writes: > Ian> The second approach is of course to write a little language which is > Ian> powerful enough to describe printf. The state machine language I > Ian> described earlier is too simple and perhaps overly cryptic. > > If we're doing that, why not use an already existing little language? I thought about that, but it doesn't quite make sense to me yet. It introduces yet another external software dependency into gcc, and it does it not for any fundamental need but for a rather limited feature--one which is used only for warnings, not for quality of generated code. (I also don't know of any embeddable little language which is really right for the problem space, although of course there are quite a few which are powerful enough to solve the problem. I think the closest existing languages to what we need are lex or awk, although I'm not aware of any easily embeddable version of either.) > The idea of letting gcc load a .so to do the checking also seems fine. > At least then the checking language is a standard one, not one we made > up. Yes. My main concerns would be * It's obviously vastly more powerful than anything we actually need, and using dlopen exposes the compiler to bugs in the implementation of the format checker--slowness, random memory clobbering, etc. * The compiler is, in its own way, a system security component. If somebody were to put format checking into a system header file which used a shared library, then substituting that shared library-- perhaps by just getting the compiler to pick up a different version of it--becomes an avenue for a complex but subtle attack on the system as a whole. Ian
Bootstrap failure on powerpc-apple-darwin8 with Ada
Howdy, My last two attempts to build mainline on darwin8 have failed with a bugbox in Ada. +===GNAT BUG DETECTED==+ | 4.1.0 20050819 (experimental) (powerpc-apple-darwin8.3.0) GCC error: | | tree check: expected class expression, have exceptional | |(constructor) in get_base_var, at ipa-utils.c: 224 | | Error detected at a-except.adb: 1411:4| | Please submit a bug report; see http://gcc.gnu.org/ bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +=== ===+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 make[2]: *** [ada/a-except.o] Error 1 make[1]: *** [stage2_build] Error 2 make: *** [bootstrap] Error 2 Previously I got this: +===GNAT BUG DETECTED==+ | 4.1.0 20050817 (experimental) (powerpc-apple-darwin8.3.0) Bus error | | Error detected at a-except.adb: 1411:4| | Please submit a bug report; see http://gcc.gnu.org/ bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +=== ===+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 make[2]: *** [ada/a-except.o] Error 1 make[1]: *** [stage2_build] Error 2 make: *** [bootstrap] Error 2 Clearly the same error, but different message. I am bootstrapping with gcc 4.0.0. This is the configure line: /Volumes/Playland/projects/gnu/gcc-stuff/gcc-HEAD/configure --prefix=/ opt/gcc410 --enable-shared \ --with-mpfr=/opt/local --with-gmp=/opt/local --enable- languages=c,ada,c++,f95,objc Thanks, Chris -- Christopher Douty <[EMAIL PROTECTED]> +1-650-367-3129 Senior Engineer, Software & Systems - AMPEX Data Systems Corp.
Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
A patch by Andrew Pinski is there: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01666.html But review was negative, so it was not commited. Hope this helps, Laurent PS: is there a PR for this one? On Fri, 2005-08-19 at 15:16 -0700, Chris Douty wrote: > Howdy, > > My last two attempts to build mainline on darwin8 have failed with a > bugbox in Ada. > > +===GNAT BUG > DETECTED==+ > | 4.1.0 20050819 (experimental) (powerpc-apple-darwin8.3.0) GCC > error: | > | tree check: expected class expression, have > exceptional | > |(constructor) in get_base_var, at ipa-utils.c: > 224 | > | Error detected at a-except.adb: > 1411:4| > | Please submit a bug report; see http://gcc.gnu.org/ > bugs.html.| > | Use a subject line meaningful to you and us to track the > bug.| > | Include the entire contents of this bug box in the > report. | > | Include the exact gcc or gnatmake command that you > entered. | > | Also include sources listed below in gnatchop > format | > | (concatenated together with no headers between > files). | > +=== > ===+ > > Please include these source files with error report > Note that list may not be accurate in some cases, > so please double check that the problem can still > be reproduced with the set of files listed. > > > > raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 > make[2]: *** [ada/a-except.o] Error 1 > make[1]: *** [stage2_build] Error 2 > make: *** [bootstrap] Error 2 > > > Previously I got this: > > +===GNAT BUG > DETECTED==+ > | 4.1.0 20050817 (experimental) (powerpc-apple-darwin8.3.0) Bus > error | > | Error detected at a-except.adb: > 1411:4| > | Please submit a bug report; see http://gcc.gnu.org/ > bugs.html.| > | Use a subject line meaningful to you and us to track the > bug.| > | Include the entire contents of this bug box in the > report. | > | Include the exact gcc or gnatmake command that you > entered. | > | Also include sources listed below in gnatchop > format | > | (concatenated together with no headers between > files). | > +=== > ===+ > > Please include these source files with error report > Note that list may not be accurate in some cases, > so please double check that the problem can still > be reproduced with the set of files listed. > > > > raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 > make[2]: *** [ada/a-except.o] Error 1 > make[1]: *** [stage2_build] Error 2 > make: *** [bootstrap] Error 2 > > > Clearly the same error, but different message. > > I am bootstrapping with gcc 4.0.0. This is the configure line: > /Volumes/Playland/projects/gnu/gcc-stuff/gcc-HEAD/configure --prefix=/ > opt/gcc410 --enable-shared \ > --with-mpfr=/opt/local --with-gmp=/opt/local --enable- > languages=c,ada,c++,f95,objc > > Thanks, > Chris >
Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
On Sat, 2005-08-20 at 00:36 +0200, Laurent GUERBY wrote: > A patch by Andrew Pinski is there: > > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01666.html > > But review was negative, so it was not commited. > > Hope this helps, > > Laurent > > PS: is there a PR for this one? Thanks to Andrew Pinski for the tip: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533 Laurent
Fwd: [RFC] - Regression exposed by recent change to compress_float_constant
Fariborz is still having problems with his mailer and has asked me to forward this.
On Aug 10, 2005, at 2:35 PM, Dale Johannesen wrote:
On Aug 10, 2005, at 12:43 PM, Fariborz Jahanian wrote:
Following patch has exposed an optimization shortcoming:
2005-07-12 Dale Johannesen <[EMAIL PROTECTED]>
* expr.c (compress_float_constant): Add cost check.
* config/rs6000.c (rs6000_rtx_cost): Adjust FLOAT_EXTEND cost.
This patch results in generating worse code for the following test case:
1) Test case:
struct S {
float d1, d2, d3;
I believe you mean double not float; the RTL snippets you give indicate this.
(insn 12 7 13 0 (set (reg:SF 59)
(mem/u/i:SF (symbol_ref/u:SI ("*LC0") [flags 0x2]) [0 S4 A32])) -1 (nil)
(nil))
(insn 13 12 14 0 (set (mem/s/j:DF (reg/f:SI 58 [ D.1929 ]) [0 .d1+0 S8 A32])
(float_extend:DF (reg:SF 59))) -1 (nil)
(nil))
However, if you try your example with float as given, you see it does not do a
direct store of constant 0 with or without the compress_float patch. IMO the
compress_float patch does not really have anything to do with this problem;
before this patch the double case was working well by accident, my patch
exposed a problem farther downstream, which was always there for the float
case.
When I put that patch in, rth remarked:
While I certainly wouldn't expect fold_rtx to find out about this
all by itself, I'd have thought that there would have been a
REG_EQUIV or REG_EQUAL note that indicates that the end result is
the constant (const_double:DF 1.0), and use that in any simplification.
Indeed there is no such note, and I suspect adding it somewhere (expand?) would fix this.
It turned out that cse does put REG_EQUIV on the insn which sets load of "LC0" to the register. So, no need to do this. It also tells me that cse is expected to use this information to do the constant propagation (which in the example test case is the next few insns). Attached patch accomplishes this task. It is against apple local branch. It has been bootstrapped and dejagnu tested on x86-darwin, ppc-darwin. Note that patch is similar to the code right before it (which is also shown in this patch), so there is a precedence for this type of a fix. If this looks reasonable, I will prepare an FSF patch.
ChangeLog:
2005-08-19 Fariborz Jahanian <[EMAIL PROTECTED]>
* cse.c (cse_insn): Use the constant to propagte
into the rhs of a set insn which is a register.
This is cheaper.
Index: cse.c
===
RCS file: /cvs/gcc/gcc/gcc/cse.c,v
retrieving revision 1.342.4.3
diff -c -p -r1.342.4.3 cse.c
*** cse.c 5 Jul 2005 23:21:50 - 1.342.4.3
--- cse.c 19 Aug 2005 18:21:56 -
*** cse_insn (rtx insn, rtx libcall_insn)
*** 5455,5460
--- 5455,5469
if (dest == pc_rtx && src_const && GET_CODE (src_const) == LABEL_REF)
src_folded = src_const, src_folded_cost = src_folded_regcost = -1;
+ /* APPLE LOCAL begin radar 4153339 */
+ if (n_sets == 1 && GET_CODE (sets[i].src) == REG
+ && src_const && GET_CODE (src_const) == CONST_DOUBLE)
+ {
+ src_folded = src_const;
+ src_folded_cost = src_folded_regcost = -1;
+ }
+ /* APPLE LOCAL end radar 4153339 */
+
/* Terminate loop when replacement made. This must terminate since
the current contents will be tested and will always be valid. */
while (1)
Index: testsuite/ChangeLog.apple-ppc
===
RCS file: /cvs/gcc/gcc/gcc/testsuite/Attic/ChangeLog.apple-ppc,v
retrieving revision 1.1.4.88
diff -c -p -r1.1.4.88 ChangeLog.apple-ppc
*** testsuite/ChangeLog.apple-ppc 15 Aug 2005 21:02:26 - 1.1.4.88
--- testsuite/ChangeLog.apple-ppc 19 Aug 2005 18:21:59 -
***
*** 1,3
--- 1,8
+ 2005-08-18 Fariborz Jahanian <[EMAIL PROTECTED]>
+
+ Radar 4153339
+ * gcc.dg/i386-movl-float.c: New.
+
2005-08-15 Devang Patel <[EMAIL PROTECTED]>
Radar 4209318
Index: testsuite/gcc.dg/i386-movl-float.c
===
RCS file: testsuite/gcc.dg/i386-movl-float.c
diff -N testsuite/gcc.dg/i386-movl-float.c
*** /dev/null 1 Jan 1970 00:00:00 -
--- testsuite/gcc.dg/i386-movl-float.c 19 Aug 2005 18:22:03 -
***
*** 0
--- 1,15
+ /* APPLE LOCAL begin radar 4153339 */
+ /* { dg-do compile { target i?86-*-* x86_64-*-* } } */
+ /* { dg-options "-O1 -mdynamic-no-pic -march=pentium4 -mtune=prescott" } */
+ /* { dg-final { scan-assembler-times "movl\[^\\n\]*" 8} } */
+
+ struct S {
+ double d1, d2, d3;
+ };
+
+ struct S ms()
+ {
+ struct S s = {0,0,0};
+ return s;
+ }
+ /* APPLE LOCAL end radar 4153339 */
Re: Fwd: [RFC] - Regression exposed by recent change to compress_float_constant
On Aug 10, 2005, at 12:43 PM, Fariborz Jahanian wrote:
> + /* APPLE LOCAL begin radar 4153339 */
> + if (n_sets == 1 && GET_CODE (sets[i].src) == REG
> + && src_const && GET_CODE (src_const) == CONST_DOUBLE)
> + {
> + src_folded = src_const;
> + src_folded_cost = src_folded_regcost = -1;
> + }
> + /* APPLE LOCAL end radar 4153339 */
I don't see how this could be right for FSF gcc. It's putting a
target specific decision into the target independent code. It is
simply not true that a constant double is always cheaper than a
register, for example. The similar case you cite, of the indirect
jump insn, really is target independent--a branch to a known
destination is always going to be cheaper than an indirect branch via
a register.
It seems possible that this could be fixed by adjusting the cost of
the CONST_DOUBLE in the target backend.
Ian
how to compile gcc
Hello, I 'd like to dig into gcc internals, and would like to compile it with -g. I can't find any document on how to do that? I tried make BOOT_CFLAGS=-g CFLAGS=-g, but it still will add '-O2' later on. Any documentation on how GCC is compiled? what are the stages of the compilation? Thanks, -Jiang
Gcc and a Garbage Collector.
Hi, With this page from Wikipedia, http://en.wikipedia.org/wiki/GNU_Compiler_Collection, in the "See also" section, there is a sentence about a Garbage collected included in GCC. Is it true ? If yes, how can I use it with my c++ source code ? (documentation, articles, tutorials...). Thanks Stephane -- Stephane Wirtel <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Gcc and a Garbage Collector.
> > Hi, > > With this page from Wikipedia, > http://en.wikipedia.org/wiki/GNU_Compiler_Collection, in the "See also" > section, > there is a sentence about a Garbage collected included in GCC. > > Is it true ? Yes. > If yes, how can I use it with my c++ source code ? (documentation, > articles, tutorials...). It is a very simple mark and sweep GC and not realy useful for most other projects. You mark each struct for GCable and all static and global variables too. You cannot have only a reference to a GCable on the stack (it has to be in a GC marked variable too) when the gc is called. -- Pinski
Re: Gcc and a Garbage Collector.
Le Friday 19 August 2005 a 20:08, Andrew Pinski ecrivait: > > > > Hi, > > > > With this page from Wikipedia, > > http://en.wikipedia.org/wiki/GNU_Compiler_Collection, in the "See also" > > section, > > there is a sentence about a Garbage collected included in GCC. > > > > Is it true ? > > Yes. > > If yes, how can I use it with my c++ source code ? (documentation, > > articles, tutorials...). > > It is a very simple mark and sweep GC and not realy useful for most other > projects. > You mark each struct for GCable and all static and global variables too. You > cannot > have only a reference to a GCable on the stack (it has to be in a GC marked > variable > too) when the gc is called. Thanks, And in the gcc documentation, can you tell me where can I find an example or a description ? Stephane -- Stephane Wirtel <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Gcc and a Garbage Collector.
On Aug 19, 2005, at 5:07 PM, Andrew Pinski wrote: Hi, With this page from Wikipedia, http://en.wikipedia.org/wiki/ GNU_Compiler_Collection, in the "See also" section, there is a sentence about a Garbage collected included in GCC. There's also boehm-gc: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ which is shipped with gcc for java's use. Mostly depends on what you're looking at the gc for - whether it's for your language, for hacking on gcc, or something else. -eric
Re: Gcc and a Garbage Collector.
> There's also boehm-gc: > > http://www.hpl.hp.com/personal/Hans_Boehm/gc/ > > which is shipped with gcc for java's use. > > Mostly depends on what you're looking at the gc for - whether it's > for your language, for hacking on gcc, or something else. Thanks Eric, -- Stephane Wirtel <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Re: Gcc and a Garbage Collector.
On Aug 19, 2005, at 8:16 PM, Stephane Wirtel wrote: It is a very simple mark and sweep GC and not realy useful for most other projects. You mark each struct for GCable and all static and global variables too. You cannot have only a reference to a GCable on the stack (it has to be in a GC marked variable too) when the gc is called. Thanks, And in the gcc documentation, can you tell me where can I find an example or a description ? in the internals manual of GCC, it is part of the sources of GCC and nothing else. You can pull it out and use it in a different project but that would very stupid. Anyways the docs are: http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type- Information -- Pinski
Re: Bootstrap failure on powerpc-apple-darwin8 with Ada
On Sat, 2005-08-20 at 00:44 +0200, Laurent GUERBY wrote: > On Sat, 2005-08-20 at 00:36 +0200, Laurent GUERBY wrote: > > A patch by Andrew Pinski is there: > > > > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01666.html > > > > But review was negative, so it was not commited. > > > > Hope this helps, > > > > Laurent > > > > PS: is there a PR for this one? > > Thanks to Andrew Pinski for the tip: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22533 I actually believe Richard may have come up with the wrong idea (using the analyze_expr hook) because Andrew didn't fully explain what is going on. What happens is that the IPA passes, not cgraph, want to analyze variables, including statics. If it was just cgraph, i would agree that modifying analyze_expr, is probably the right solution. But for general IPA working on the cgraph + GIMPLE level, as is what is happening here, I think we really need to do something about static variable initializers so they are in GIMPLE. Richard, I assume you'd rather have us hack around this for stage3 somehow, and come up with a way to gimplify the static var constructors for 4.2? (i guess that means creating a new init function and shoving them in there, and marking it special somehow) Or do you have another idea? This is not a case we can just ignore the constructors, they contain addressof operations we need to be able to see to come up with the right answers for type escape analysis, static variable address taken, etc :( --Dan
