Re: GCC optimizes integer overflow: bug or feature?

Matthew Woehlke <[EMAIL PROTECTED]> writes: > That said, I've seen even stranger things, too. For example: > > foo->bar = make_a_bar(); > foo->bar->none = value; > > being rendered as: > > call make_a_bar > foo->bar->none = value > foo->bar = That would obviously be a bug in the compiler. >

Re: Reload Pass

Rajkishore Barik <[EMAIL PROTECTED]> writes: > Does anyone know of any document describing (in details) the reload phase > of GCC? There isn't one. The closest such document is http://gcc.gnu.org/wiki/reload which is accurate despite, or perhaps because of, starting out by equating reload w

Re: SSA_NAMES: should there be an unused, un-free limbo?

Jeffrey Law <[EMAIL PROTECTED]> writes: > On Thu, 2006-12-21 at 11:55 -0500, Diego Novillo wrote: > > Robert Kennedy wrote on 12/21/06 11:37: > > > > > The situation is that some SSA_NAMEs are disused (removed from the > > > code) without being released onto the free list by > > > release_ssa_n

Re: SSA_NAMES: should there be an unused, un-free limbo?

Jeffrey Law <[EMAIL PROTECTED]> writes: > On Thu, 2006-12-21 at 10:08 -0800, Ian Lance Taylor wrote: > > First, let's go ahead and define an orphan. An orphan is an SSA_NAME > which has SSA_NAME_DEF_STMT pointing to a statement which does not > appear in the IL.

Re: GCC optimizes integer overflow: bug or feature?

Paul Eggert <[EMAIL PROTECTED]> writes: > That probably sounds vague, so here's the code that beta > gcc -O2 actually broke (which started this whole thread): > > int j; > for (j = 1; 0 < j; j *= 2) > if (! bigtime_test (j)) > return 1; It's interesting to note that in

Re: Saving the Tree declaration node in GCC 4.1.1.

"Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > Before emitting a call instruction, i need to check for function > attributes. Based on that i need to emit the corresponding call > instruction. For that, before emitting the call instruction, i check > for the attributes of the called function throu

Re: Gprof and shared libraries

"Christian Sturz" <[EMAIL PROTECTED]> writes: > I've a larger project that consists of several shared libraries. > The compilation is done by autoconf and automake. One of the libraries > seems to be slow so I would like to profile it. My idea was to use gprof > (I'm using gcc 3.4.6). First, I mod

Re: does zlib really need to build multilib?

Jack Howarth <[EMAIL PROTECTED]> writes: >I noticed that in gcc trunk and gcc 4.2 branch > that multilib builds of zlib occur. Does gcc > actually use the multlib zlib? For instance on > x86_64 linux does the 32-bit zlib get used or on > Darwin does the 64-bit zlib get used? We are > consideri

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an > optional second argument specifying the default optimization > options for GCC. These optimizations now default to "-O2 -fwrapv" > instead of to "-O2". This partly at

Re: Compiler loop optimizations

Christian Sturn <[EMAIL PROTECTED]> writes: > Thank you for your answer. Is there any chance to have gcc dump out > an optimized code in the form the source level language, e.g. can I run > gcc with some optimizations and see how the compiler modified my C > source code? You can get an approxima

Re: Compiler loop optimizations

Christian Sturn <[EMAIL PROTECTED]> writes: > On Fri, 29 Dec 2006 15:03:51 -0500 > Robert Dewar <[EMAIL PROTECTED]> wrote: > > > > There is no support for dumping actual valid source code, though, > > > and it is unlikely that there ever will be. > > > > And indeed it is not in general possible,

Re: [heads-up] disabling "../configure --disable-bootstrap && make bootstrap"

[EMAIL PROTECTED] (Richard Kenner) writes: > > I don't believe anyone else considers this important. > > The history on this sort of thing is that people don't pay attention > until it happens and then everybody starts yelling about bootstrap > time increasing ... > > > - Build supporting lib

Re: RFC: SMS problem with emit_copy_of_insn_after copying REG_NOTEs

Andrew Pinski <[EMAIL PROTECTED]> writes: > > > > > Hi, > > > thanks for testing. I've bootstrapped/regtested this variant of patch > > > and comitted it as obvious. > > > > Since this is an insn, we should not be copying it as it is just a link to > > that > > insn. > > > > Attached is a pat

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > for this specific function (vrp_int_const_binop), I'm issuing a > warning inside the else-if branch that tests for the overflowed > result. I'm unclear why that is a false positive since the result is > known to overflow. Could you elaborate? Wit

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: > > Note that -fwrapv also _enables_ some transformations on signed > > integers that are disabled otherwise. We for example constant fold > > -CST for -fwrapv while we do not if signed overflow is undefined. > > Would you change those? > > I don't unde

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: > > > > Note that -fwrapv also _enables_ some transformations on signed > > > > integers that are disabled otherwise. We for example constant fold > > > > -CST for -fwrapv while we do not if signed overflow is undefined. > > > > Would you change those? >

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > > >> http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html > >> and > >> http://www.suse.de/~gcctest/SPEC/CINT/sb-vangelis-head-64/recent.html > >> > > Note the distinct drop in performance acro

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > Robert Dewar <[EMAIL PROTECTED]> writes: > > > We have not seen ONE imaginary example, let > > alone a real example, where the optimziation of loop invariants > > (by far the most important optimization in the class we are > > discussing) would break exis

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: > > But didn't this thread get started by a real program that was broken > > by an optimization of loop invariants? Certainly I got a real bug > > report of a real problem, which you can see here: > > > > http://lists.gnu.org/archive/html/bug-gnulib/200

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > I do hope your and Richard G's constructive search for middle ground > will find echoes within the middle-end maintainers. This seems likely, since Richard and I are two of the three middle-end maintainers, and I don't recall hearing from the other o

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > Ralf Wildenhues suggested bugzilla originally, but Andrew Pinski > responded that the > problem "has been observed many, many times and talked about a lot of > time on this list" and implied strongly that t

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Bruce Korb <[EMAIL PROTECTED]> writes: > WRT strict aliasing, I've never seen any data that indicated that the > language change was compelling. Consequently, as best I can tell it > was a marginal optimization improvement. So, I doubt its value. > Still, it should have had compiler warnings in

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Bruce Korb <[EMAIL PROTECTED]> writes: > > 2) Add an option like -fstrict-signed-overflow which controls those > >cases which appear to be risky. Turn on that option at -O2. > > Not a good plan. -O2 should be constrained to disrupting very few > applications. (e.g. loop unrolling seems unl

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[EMAIL PROTECTED] (Richard Kenner) writes: > The question that I'd like to understand the answer to is what kinds of > optimizations DO we get by having VRP optimized signed overflow. Is it just > the elimination of tests on overflow? If so, then it strikes me as > definitely wrong since those t

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

Paul Eggert <[EMAIL PROTECTED]> writes: > Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > > Also, it does not make sense to me to lump together all potentially > > troublesome optimizations under a single name. > > As a compiler developer, you see the trees.

Re: -pg problem

Adam Sulmicki <[EMAIL PROTECTED]> writes: > can someone help me understand what is going on? > > are the -p and -pg options supposed to work? This question is not appropriate for gcc@gcc.gnu.org, which is a mailing list for gcc developments. It is appropriate for [EMAIL PROTEC

Re: gcc, mplayer and profile (mcount)

Adam Sulmicki <[EMAIL PROTECTED]> writes: > In spirit making OSS better, I took the extra effor to report > findings back to both lists. In reward I got flamed on both list. You got flamed on the gcc list? I don't see any flames there. All I told you was to use the gcc-help mailing

Re: gcc, mplayer and profile (mcount)

"Seongbae Park" <[EMAIL PROTECTED]> writes: > I remember someone wanting to provide his own mcount(). > Presumably, mcount() is weak in libc to cover such a use case ? Yes, mcount() is weak in libc. But it seems to me that you can provide your own mcount even if it has to be named _mcount, since

Re: gcc, mplayer and profile (mcount)

Andrew Haley <[EMAIL PROTECTED]> writes: > Trivia time: what is the longest delay between a bug being committed > to gcc before someone notices and a fix being committed? This one is > eleven years and eight months. I wonder if we have a record. As it happens, I can beat that. I've found a bug

Re: How to dedicate a register for special purpose in gcc?

"吴曦" <[EMAIL PROTECTED]> writes: > How can I dedicate a register for special purpose, that means, > the dedicated register only appears in the inserted code of my own, > but never allocated in the rest of code. I have read some doc(gcc int) > about the register usage but still have no idea. This

Re: gcc 3.4 > mainline performance regression

Andrew Haley <[EMAIL PROTECTED]> writes: > It appears that memory references to arrays aren't being hoisted out > of loops: in this test case, gcc 3.4 doesn't touch memory at all in > the loop, but 4.3pre (and 4.2, etc) does. > > Here's the test case: > > void foo(int *a) > { int i; >

Re: Build snapshots according to a more regular schedule

David Edelsohn <[EMAIL PROTECTED]> writes: > Are 4.0 snapshots still necessary? I suspect they should be > discontinued. 4.0 still seems to be regarded as an active branch. I don't mind closing it, myself. Does anybody think we should have a 4.0.4 release? Ian

Re: passing arguments in emit_libraray_call

"吴曦" <[EMAIL PROTECTED]> writes: > I want to use emit_library_call to output a library call to "printf". > The question is how to pass a format string argument? See, e.g., how STRING_CST is handled in expand_expr_real_1. > Also, in the comment of emit_library_call mentions: > > "The rtx values

Re: SSE (Pentium 3) - Is this correct?

"mal content" <[EMAIL PROTECTED]> writes: > Apologies if this is the wrong list. It's the wrong list. This should go to [EMAIL PROTECTED] Please send any followups there. Thanks. > float *vector_add4f(float va[4], const float vb[4]) > { > va[0] += vb[0]; > va[1] += vb[1]; > va[2] += vb[

Re: About STACK ALIGNMENT

"Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > 1. How do i get the stack alignment size of a particular target? >Does #define STACK_BOUNDARY 32 serve this purpose? STACK_BOUNDARY is used to express the alignment maintained by the hardware. In practice this means that gcc can expect the stack

Re: RFC: Mark a section to be discarded for DSO and executable

"H. J. Lu" <[EMAIL PROTECTED]> writes: > With LTO, an object file may contain sections with IL, which > can be discarded when building DSO and executable. Currently we can't > mark such sections with gABI. With GNU linker, we can use a > linker script to discard such sections. But it will be more

Re: Tricky(?) aliasing question.

Sergei Organov <[EMAIL PROTECTED]> writes: > Below are two example functions foo() and boo(), that I think both are > valid from the POV of strict aliasing rules. GCC 4.2 either warns about > both (with -Wstrict-aliasing=2) or doesn't warn about any (with > -Wstrict-aliasing), and generates the as

Re: Build shared libraries with -Bsymbolic-functions

"H. J. Lu" <[EMAIL PROTECTED]> writes: > With the new linker switches, -Bsymbolic-functions and > --dynamic-list-cpp-new, we can improve shared library > performance in gcc. This change will build libstdc++.so with > -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it > to other libra

Re: Enforcing order of execution for function arguments

"Chris Jefferson" <[EMAIL PROTECTED]> writes: > One thing which comes up regularly in various C and C++ messageboards > is that statements like "f() + g()" and "a(f(), g())" do not declare > which order f() and g() will be executed in. > > How hard would it be to fix the order of execution in gcc

Re: Aliasing error in man page?

Andrew Haley <[EMAIL PROTECTED]> writes: > --- > *(void **) (&cosine) = dlsym(handle, "cos"); > --- > That is a strict-aliasing error, is it? Yes, and a see

Re: RFC: Wextra digest (fixing PR7651)

"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: > The goal is to fix PR7651 and convert Wextra into a super-option, that > is an -W* option that just enables other options but it doesn't emit > warnings by itself (other super-options are Wall and Wunused). Thanks again for tackling this. These

Re: RFC: Wextra digest (fixing PR7651)

"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes: > On 11 Jan 2007 15:48:36 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > > These issues are tricky because on the one hand we don't want too many > > different options, and on the other hand we

Re: error when porting from g++ for hp-ux to g++ for linux

"Puetz, Oliver P11M22" <[EMAIL PROTECTED]> writes: > here's a little sample code, which could be compiled with g++ 3.01 under > hp-ux, but when compiled with g++ 3.4.6 under linux, following error > occured: > > sample.c: In member function 'T C2::PROC(T)': > sample.c:19: error: 'c1i' was not d

Re: Invariant division

"drizzle drizzle" <[EMAIL PROTECTED]> writes: > Does gcc do an divison by constant optimization for any 16 bit > architecture. Can anyone point me to where it does that ? expand_divmod in expmed.c. Ian

Re: Unsure about a new warning in mainline

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > Paolo Carlini <[EMAIL PROTECTED]> writes: > > [...] > > | >Specifically, for PR 30465 "((T)1 << 31) - 1" is potentially undefined > | >when T is a 32-bit signed type, but well-defined if T is unsigned or > | >wider than 32-bits. > | > > | FYI: this

Re: Unsure about a new warning in mainline

Paolo Carlini <[EMAIL PROTECTED]> writes: > Therefore, I'd like to apply to mainline the below (finishing testing > on x86-linux), can you check it? > > Thanks in advance, > Paolo. > > / > 2007-01-15 Ian Lance Taylor <[EMAIL PROTECTED]> >

Re: Do we need assemble_external_libcall?

"H. J. Lu" <[EMAIL PROTECTED]> writes: > process_pending_assemble_externals will be called at the end, > which calls assemble_external_real on all external symbols. > Do we still need TARGET_ASM_EXTERNAL_LIBCALL? Why can't > assemble_external_real handle it? Look at, e.g., mcore_external_libcall

Re: Do we need assemble_external_libcall?

"H. J. Lu" <[EMAIL PROTECTED]> writes: > > Look at, e.g., mcore_external_libcall in mcore.c, and at > > ASM_OUTPUT_EXTERNAL_LIBCALL in i386/cygming.h. You need to handle > > cases like those somehow. I agree that we could rework the way that > > TARGET_ASM_EXTERNAL_LIBCALL works today, but no ma

Re: Miscompilation of remainder expressions

Joe Buck <[EMAIL PROTECTED]> writes: > I suggest that those who think this is a severe problem are the ones who > are highly motivated to work on a solution. An efficient solution could > be tricky: you don't want to disrupt pipelines, or interfere with > optimizations that rely on recognizing th

Re: Miscompilation of remainder expressions

David Daney <[EMAIL PROTECTED]> writes: > Andrew Haley wrote: > > Ian Lance Taylor writes: > > > Joe Buck <[EMAIL PROTECTED]> writes: > > > > > I suggest that those who think this is a severe problem are > > the > > >

Re: Miscompilation of remainder expressions

Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > Ian, do you believe something along the line of > > # > I mean, could not we generate the following for "%": > # > > # > rem a b := > # > if abs(b) == 1 > # > return 0 > # > return a b > # > # On x86 processors tha

Re: meaning of typedef ...and something more

"Laura Tardivo" <[EMAIL PROTECTED]> writes: > Hi, my question is about the meanig of qualifiers in combination with > typedefs. For example: > > typedef int function1(); > typedef int function2(); > ... > typedef function1 transition1; > typedef function2 transition2; > ... > int Def_Fun( volati

Re: Preventing warnings

Richard Stallman <[EMAIL PROTECTED]> writes: > In Emacs we have a macro that tends to produce the warning > >comparison is always false due to limited range of data type > > when compiling for 64-bit machines. EMACS_INT is 64 bits > in that case. Here is the macro: > > #define FIXNUM_OVER

Re: Miscompilation of remainder expressions

Joe Buck <[EMAIL PROTECTED]> writes: > On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote: > > From a performance/convenience angle, the best place to handle this is > > either libc or the kernel. Either of these can quite easily fix up > > the operands when a trap happens, with zero pe

Re: Miscompilation of remainder expressions

Robert Dewar <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > > We do want to generate a trap for x / 0, of course. > > Really? Is this really defined to generate a trap in C? > I would be surprised if so ... As far as I know, but I think it would be a sur

Re: gcc compile time support for assumptions

Abramo Bagnara <[EMAIL PROTECTED]> writes: > I'd like to know if gcc has implemented some generic way to help > optimizer job by allowing programmers to specify assumptions (or > constraints). The answer is no, there is nothing quite like you describe. But I think it would be a good idea. Ian

Re: C Parser

"Paulo J. Matos" <[EMAIL PROTECTED]> writes: > I was quite surprised to see that the C Parser was manually > implemented and you didn't use any parser generator. > > I would be curious regarding this decision. I would think the > development of a C parser would be an almost unsurmountable task an

Re: Where the languages meet...

"Paulo J. Matos" <[EMAIL PROTECTED]> writes: > After reading the internals of gcc wikibooks some questions come up. > So, gcc has front end for C, C++, java, fortran, etc.. > All these languages have a frontend which parse into AST and then > GIMPLE which is converted to RTX and then assembly. Now

Re: gcc compile time support for assumptions

Andrew Haley <[EMAIL PROTECTED]> writes: > Ian Lance Taylor writes: > > Abramo Bagnara <[EMAIL PROTECTED]> writes: > > > > > I'd like to know if gcc has implemented some generic way to help > > > optimizer job by allowing program

Re: Getting a tree node for a field of a variable

"Ferad Zyulkyarov" <[EMAIL PROTECTED]> writes: > Please, would you suggest me any clues on how to get a tree node for a > field of a variable within the AST. Look in tree.def. Given the RECORD_TYPE node, walk down TYPE_FIELDS looking for the FIELD_DECL that you want. To assign to a field use a

Re: Controlling Register Allocation - GCC 4.1.1

"Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > I am having some problem while allocating floating point registers in GCC > 4.1.1. > As of now my target does not have floating point registers. To support > floating point operations, i added 8 floating point registers that i > want the gcc to allo

Re: Controlling Register Allocation - GCC 4.1.1

Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > I have done the following: > > 1. Defined them in FIXED_REGISTERS, CALL_USED_REGISTERS. > > 2. Ordered them using REG_ALLOC_ORDER. > > 3. Created a separate class in enum reg_class (FLOAT). > > 4. Assigned

Re: trying to fix a bug in m6812 front-end

"Sean D'Epagnier" <[EMAIL PROTECTED]> writes: > -> (insn 10 9 11 (nil) (set (reg:HI 54) > -> (and:HI (reg:HI 53) > -> (mem:HI (mem/f:HI (plus:HI (reg/f:HI 49 virtual-stack-vars) > -> (const_int 2 [0x2])) [0 b+0 S2 A16]) [0 S2 A8]))) > -1 (nil) > ->

Re: innovative new build failure

Mike Stump <[EMAIL PROTECTED]> writes: > Here is an innovative new build failure, as seen on i686-apple-darwin9: > > ../../gcc/gcc/expmed.c:4179: warning: signed and unsigned type in > conditional expression > make[3]: *** [expmed.o] Error 1 > make[2]: *** [all-stage2-gcc] Error 2 Yikes, my faul

Re: innovative new build failure

Mike Stump <[EMAIL PROTECTED]> writes: > Here is an innovative new build failure, as seen on i686-apple-darwin9: > > ../../gcc/gcc/expmed.c:4179: warning: signed and unsigned type in > conditional expression > make[3]: *** [expmed.o] Error 1 > make[2]: *** [all-stage2-gcc] Error 2 Fixed like so.

Re: raising minimum version of Flex

Ben Elliston <[EMAIL PROTECTED]> writes: > I think it's worth raising the minimum required version from 2.5.4 to > 2.5.31. I want to point out that Fedora Core 5 appears to still ship flex 2.5.4. At least, that is what flex --version reports. (I didn't bother to check this before.) I think we

Re: raising minimum version of Flex

"Steven Bosscher" <[EMAIL PROTECTED]> writes: > On 21 Jan 2007 22:13:06 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > Ben Elliston <[EMAIL PROTECTED]> writes: > > > > > I think it's worth raising the minimum required version fro

Re: Signed int overflow behaviour in the security context

Andreas Bogk <[EMAIL PROTECTED]> writes: > It is my fear that the existing behaviour of gcc when used without > -fwrapv breaks a lot of code out there that was written with the > implicit assumption that signed ints would overflow the way the > underlying machine integers do. More importantly, so

Re: Signed int overflow behaviour in the security context

Andreas Bogk <[EMAIL PROTECTED]> writes: > The case is clear when an if branch is folded away, because some > comparison is folded that would not have been under twos-complement > semantics. This is a pattern that probably doesn't happen all that much > in code out there, except in post-facto ove

Re: Signed int overflow behaviour in the security context

Andreas Bogk <[EMAIL PROTECTED]> writes: > > Making it defined and wrapping doesn't help at all. It just means you > > write different checks, not less of them. > > You have just seen somebody who can be considered an expert in matters > of writing C sofware come up with a check that looks correc

Re: Which optimization levels affect gimple?

"Paulo J. Matos" <[EMAIL PROTECTED]> writes: > Which optimization levels affect gimple? > I've tried for a program to check what kind of gimple code you get > with -fdump-tree-gimple and -O0 and -O3 have different results, > however, -O3 and -O9 have exactly the same output. Will -Ox for x > 3, >

Re: subreg_get_info vs mode restrictions in registers?

DJ Delorie <[EMAIL PROTECTED]> writes: > subreg_get_inf() in rtlanal.c blindly assumes that any hard register > can hold any smaller-than-native mode: > > nregs_ymode = hard_regno_nregs[xregno][ymode]; > . . . > && (GET_MODE_SIZE (ymode) % nregs_ymode) == 0) > > However, there are regi

Re: subreg_get_info vs mode restrictions in registers?

DJ Delorie <[EMAIL PROTECTED]> writes: > Here's an example of bad assumptions. The current code calculates the > subreg location BEFORE checking to see if such a subreg is legal. > This patch moved the legality check before the location calculations. > With this patch, I can build gcc's libraries

Re: initialization and enums in new version of gcc

"Laura Tardivo" <[EMAIL PROTECTED]> writes: > I whant to know if the enum definition was changed in the last versions of > gcc because in the ansi C you can not define: > > enum COLOR{RED,GREEN,}; > > the last comma only is correct if you are defining an initialization of a > variable. But it

Re: Signed int overflow behaviour in the security context

Andreas Bogk <[EMAIL PROTECTED]> writes: > Then maybe it shouldn't be the default in autoconf. But wasn't -O3 the > set of optimizations considered potentially unsafe? No. -O3 is a set of optimizations which are useful for many program but which will cause a substantial number of programs to ru

Re: Can C and C++ object files be linked into an executable?

Ray Hurst <[EMAIL PROTECTED]> writes: > Maybe everybody has misunderstood. These are tool issues not basic C > programming. Object file format has nothing to do with C programming. > More specifically they are linker issues. > > Is the ABI format different between C and C++ object files. If you

Re: After GIMPLE...

"Paulo J. Matos" <[EMAIL PROTECTED]> writes: > I've been looking into the gcc sources and I'm somewhat confused. > Are gcc/g++ comepletely independent programs or do they share a backend? In the source code, they share a backend. As executables, they are different programs: cc1 and cc1plus. > T

Re: Interesting build failure on trunk

Ismail Dönmez <[EMAIL PROTECTED]> writes: > I am getting this when I try to compile gcc trunk: > > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe > -fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall -Wwrite-strings > -Wstrict-prototypes > -Wmissing-prototypes

Re: Who should fix platforms broken by extern inline hack?

"François-Xavier Coudert" <[EMAIL PROTECTED]> writes: > There are two platforms on which mainline is broken: > * bootstrap is broken for i386-netbsd, see PR30058 > * the compiler built on i386-mingw32 is unusable, see PR30589 > > Both regressions were introduced by Geoffrey Keating > (http://

Re: How to get rid of attribute(mode(word))?

Eric Christopher <[EMAIL PROTECTED]> writes: > > One target is to identify more places where we can get rid of > > _Unwind_Word. > > Other places exist where we definitely need a data type like > > _Unwind_Word > > representing a general purpose register. So we have to find a way > > to define >

Re: how to avoid duplicate warnings

Silvius Rus <[EMAIL PROTECTED]> writes: > I want to avoid duplicate warnings. I thought of a few ways, but none > seems perfect. Can you please advise which of the following I should > choose, suggest alternatives, or let me know if a solution exists. It may work to set and check TREE_NO_WARNIN

Re: false 'noreturn' function does return warnings

"Zack Weinberg" <[EMAIL PROTECTED]> writes: > Back in 2000 I wrote a really simple patch that caused gcc to treat an > ASM_OPERANDS that clobbered "pc" as a control flow barrier, exactly > for this problem. > > http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00190.html > > I still think it was a go

Re: false 'noreturn' function does return warnings

Joe Buck <[EMAIL PROTECTED]> writes: > On Tue, Feb 06, 2007 at 04:14:30PM -0800, Ian Lance Taylor wrote: > > I also think it would be good to have one option affecting it: turn > > __builtin_unreachable() into an abort(), or turn it into a "cannot be > > reac

Re: ICE in gcc/libgcc2.c:566 (gcc trunk)

gt; # ./cc1 -quiet -m64 -O1 test.c -o test.o > > Any ideas? The test case works for me. Note that I've committed several cleanup patches for lower-subreg.c over the last several days. In particular, do you have this change in your sources? 2007-02-01 Ian Lance Taylor <[EM

Re: ICE in gcc/libgcc2.c:566 (gcc trunk)

Hanno Meyer-Thurow <[EMAIL PROTECTED]> writes: > sorry to bother again. I reduced the code (attached) that segfaults here > on Core 2 Duo [1]. If I add -fno-split-wide-types the code does not segfault. > That flag comes from your patchset [2]. > > execute: > # ./cc1 -quiet -m64 -O1 test.c -o tes

Re: "error: unable to generate reloads for...", any hints?

"吴曦" <[EMAIL PROTECTED]> writes: > I observe that there is a ld instruction in 3rd alternative, so I add > a new define_insn before it in the hope that it will be matched > firstly. It doesn't work that way. Your new instruction will wind up matching all move instructions. Reload will crash bec

Re: "error: unable to generate reloads for...", any hints?

cc internal p259? (Please don't top post. Thanks.) It means what it says. The effect is that only the first insn in the MD file is used, and the subsequent ones are ignored. This is rarely useful. Ian > 08 Feb 2007 00:09:21 -0800, Ian Lance Taylor <[EMAIL PROTECTED]>: > > "

Re: Build fail

Kai Ruottu <[EMAIL PROTECTED]> writes: > Ok, the traditional "evolutionary" method is to not reinvent the wheel > with the already tested target components but let then be as they are > and produce only the stuff required for the new $host, the GNU > binutils and the GCC sources. NOT the target

Re: Division by zero

"Jie Zhang" <[EMAIL PROTECTED]> writes: > But now gcc seems to optimize it away. For the following function: > > $ cat t.c > #include > void foo (int rc) > { > int x = rc / INT_MAX; > x = 4 / x; > } I believe we still keep division by zero in general. In your example it gets optimized away

Re: Build fail

Kai Ruottu <[EMAIL PROTECTED]> writes: > For which existing targets the prebuilt C libraries are missing? Or > which are the > targets which don't have any "suitable", "compatible" or something C library > which could serve as that temporary bootstrap "target C library" > during the GCC > build?

Re: GCC 4.1.2 RC2

Mark Mitchell <[EMAIL PROTECTED]> writes: > But, aren't big C++ shared libraries rather different? Does KDE > actually use throw() everywhere, or visibility attributes? But, > presumably, most people don't replace the implementation of > ScrollBar::ScrollUp or whatever. I'd be happy to know I'm

Re: Some thoughts and quetsions about the data flow infrastracture

"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes: > I know some work is being done on incremental df analysis. It could > decrease time for rescanning RTL between passes. Let us hope on this. My understanding is that on dataflow-branch the DF information is now fully incremental. I don't real

Re: gcc port to StarCore

David Livshin <[EMAIL PROTECTED]> writes: > x.c: In function ‘bar’: > x.c:13: error: unrecognizable insn: > (jump_insn 26 25 27 2 (set (pc) > (reg:SI 52)) -1 (nil) > (nil)) > x.c:13: internal compiler error: in extract_insn, at recog.c:2084 > > > The .md file defines ( mandatory ) "i

Re: Disable auto-generation of strncpy on ppc?

Etienne Lorrain <[EMAIL PROTECTED]> writes: > Is there a magic flag? I want to test the source for null pointer... This question would be appropriate on the mailing list [EMAIL PROTECTED], not on [EMAIL PROTECTED] Please take any followups gcc-help. Thanks. I don't actually understand the que

Re: gcc port to StarCore

David Livshin <[EMAIL PROTECTED]> writes: > >> x.c: In function ‘bar’: > >> x.c:13: error: unrecognizable insn: > >> (jump_insn 26 25 27 2 (set (pc) > >> (reg:SI 52)) -1 (nil) > >> (nil)) > >> x.c:13: internal compiler error: in extract_insn, at recog.c:2084 > >> > >> > >> The .md file

How should __attribute__ ((gnu_inline)) behave?

Should __attribute__ ((gnu_inline)) be treated the same as a gnu89 extern inline definition? Or should the extern part be optional? That is, should there be a difference between these two definitions? extern __attribute__ ((gnu_inline)) inline int foo () { return 0; } __attribute__ ((gnu_inli

Re: RFC: vectorizer cost model

"Linthicum, Tony" <[EMAIL PROTECTED]> writes: > * Would using a tree-level API like estimate_num_insns be superior > to using a simple cost of 1 per statment? For this sort of calculation, I would guess not. I would imagine that on most processors the cost of a single vector instruction is

Re: it'urgent please help me!!!!!!!!!!!!!!!!!!!!!!!!!!!!

"sameer sinha" <[EMAIL PROTECTED]> writes: > Please can any one tell me how to bulid gcc newer version for > generating > code for i960MC processor. > is there any switch to generate coed for i960MC or i will > have to build it first > for target i960. >

Re: warning: source missing a mode?

Markus Franke <[EMAIL PROTECTED]> writes: > ---snip--- > ;; > ;; calls that return int in r1 > ;; > (define_insn "call_val_internal_return_r1" > [(parallel [(set (reg:SI 1) > (call (match_operand:QI 0 "sym_ref_mem_operand" "") > (match_operand 1 "" "i")))

Re: Porting GCC/ GDB help ::Porting the configuration scripts

Mans <[EMAIL PROTECTED]> writes: > Hi i've been put into a project in which the GDB residing on the host machine > should control the programs running on the target(wic has its (own made) > specific processor); I am very much new into all this and as my first task > : i have been assigned the ta

<    1   2   3   4   5   6   7   8   9   10   >