Re: GCC optimizes integer overflow: bug or feature?

* Andrew Pinski: > A simple loop like: > int foo () > { > int a[N]; > int i; > int n; > > for (i = 0; i <= n; i++) > ca[i] = 2; > } > > we cannot find how many iterations it runs without knowing that signed > types overflow. In this case, the assumption is not needed because the lac

Re: GCC optimizes integer overflow: bug or feature?

* Paolo Bonzini: > Interesting read. I agree with the proposed fix; however, note that > GCC does not make the result of overflowing signed left-shifts > undefined, exactly because in this case the overflow is relied upon by > too many existing programs Is this documented somewhere? Without doc

Re: GCC optimizes integer overflow: bug or feature?

* Joseph S. Myers: > On Tue, 19 Dec 2006, Florian Weimer wrote: > >> * Paolo Bonzini: >> >> > Interesting read. I agree with the proposed fix; however, note that >> > GCC does not make the result of overflowing signed left-shifts >> > undefined,

Re: GCC optimizes integer overflow: bug or feature?

* Robert Dewar: > What is (a*2)/2 optimized to? certainly it has the value a if you > wrap, Huh? Isn't (INT_MAX*2)/2 negative (and thus not equal to INT_MAX) in 2-complement arithmetic?

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

* Andrew Pinski: >> If what you propose is the only way out, and there is no way to make >> GCC optimizers reasonable, then I believe Paul's proposal is the next >> option. > > But that still does not address the issue is that this is not just about > GCC any more since autoconf can be used many

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

* Daniel Berlin: > OTOH, people who rely on signed overflow being wraparound generally > *know* they are relying on it. > Given this seems to be some small number of people and some small > amount of code (since nobody has produced any examples showing this > problem is rampant, in which case i'm

Re: Signed int overflow behaviour in the security context

* Joe Buck: > You appear to mistakenly believe that wrapping around on overflow is > a more secure option. It might be, but it usually is not. There > are many CERT security flaws involving integer overflow; the fact > that they are security bugs has nothing to do with the way gcc > generates co

Re: Signed int overflow behavior in the security context

* Paul Schlie: >> People always say this, but they don't really realize what they are >> saying. This would mean you could not put variables in registers, and >> would essentially totally disable optimization. > > - can you provide an example of a single threaded program where the > assignment of

Re: vsftpd 2.0.5 vs. gcc 4.1.2

* BuraphaLinux Server: > Does anybody have a patch or know the trick to fix this? Debian has got a patch. I think the error message is wrong, it's a const mismatch in pointer conversion, not an actual assignment.

Re: vsftpd 2.0.5 vs. gcc 4.1.2

* Andrew Pinski: >> >> * BuraphaLinux Server: >> >> > Does anybody have a patch or know the trick to fix this? >> >> Debian has got a patch. I think the error message is wrong, it's a >> const mismatch in pointer conversion, not an actual assignment. > > Actually it is a bug in glibc's header

Building mainline and 4.2 on Debian/amd64

Is there a convenient switch to make GCC bootstrap on Debian/amd64 without patching the build infrastructure? Apparently, GCC tries to build 32-bit variants of all libraries (using -m32), but the new compiler uses the 64-bit libc instead of the 32-bit libc, hence building them fails. I don't need

Re: Building mainline and 4.2 on Debian/amd64

* Steven Bosscher: > On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote: >> I don't need the 32-bit libraries, so disabling their compilation >> would be fine. --enable-targets at configure time might do the trick, >> but I don't know what arguments are a

Re: Building mainline and 4.2 on Debian/amd64

* Andrew Pinski: > On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote: >> >> I'll try, but I doubt it. According to the installation >> documentation, amd64 is not a multilib target. > > HUH??? Which documentation? I misinterpreted the installation

Re: Building mainline and 4.2 on Debian/amd64

* Andrew Pinski: > Actually it brings up an even more important thing, distros that don't > include a 32bit user land is really just broken. Are they? I haven't run into problems yet. (And pretty please, I misread the documentation. It does *not* state that amd64 is not a multilib target. Sor

Re: error: "no newline at end of file"

* Manuel López-Ibáñez: > C++ preprocessor emits errors by default for nonconformant code, > following the C++ frot-end default behaviour. Neither the C standard nor the C++ standard imposes any requirements on concrete source code representation, so it's not quite right to blame this issue on non

Re: error: "no newline at end of file"

* Ian Lance Taylor: > I don't think we necessarily have to change anything. Yes, I think that the standard does not require a particular approach to this problem. > But I think that Florian's point is that we don't have to confuse the > concrete implementation with the abstract source representa

Re: Integer overflow in operator new

* Karl Chen: > "4 * n", unchecked, is vulnerable to integer overflow. On IA-32, > "new int[0x4001]" becomes equivalent to "new int[1]". I've > verified this on gcc-2.95 through 4.1. For larger objects the > effects are exaggerated; smaller counts are needed to overflow. This PR19351, by th

Re: Integer overflow in operator new

* Joe Buck: > Consider an implementation that, when given > >Foo* array_of_foo = new Foo[n_elements]; > > passes __compute_size(elements, sizeof Foo) instead of n_elements*sizeof Foo > to operator new, where __compute_size is > > inline size_t __compute_size(size_t num, size_t size) { >

Re: Integer overflow in operator new

* Ross Ridge: > Florian Weimer writes: >>I don't think this check is correct. Consider num = 0x3334 and >>size = 6. It seems that the check is difficult to perform efficiently >>unless the architecture provides unsigned multiplication with overflow >>

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtual destructor` warning.

* Jonathan Wakely: > e.g. this is undefined behaviour: > > class Base {}; > class Derived : public Base {}; > > Base* p = new Derived; > delete p; Wouldn't it make more sense to issue the warning at the point of the delete, then?

Re: MetaC++ announcement

* Stefan Strasser: > What? > - > MetaC++ > It is a library which is able to read and write C++ source code and > makes the tree available to its clients by API and by a XML format it > can read and write. > Parsing is done by a patched GCC. > The tree is a representation of language constructs

Re: __builtin_cpow((0,0),(0,0))

* Robert Dewar: > Marcin Dalecki wrote: > >> There is no reason here and you presented no reasoning. But still >> there is a >> *convenient* extension of the definition domain for the power of >> function for the >> zero exponent. > > The trouble is that there are *two* possible convenient extensi

Re: GCC Status Report (2005-03-09)

* Joe Buck: > If it is only Debian on non-shipped platforms, it would be reasonable to > ask the Debian x64-64 people to apply the one-line patch to glibc pointed > to by the PR. It could be a hassle for them now because of the sarge > freeze, though, so maybe fixincludes would be the way to go.

Re: Copyright status of example code in Bugzilla - how to deal with when writing testcases.

* Robert Dewar: > Unfortunately, you can't rely on sane judges, since the plaintiff can > always demand a jury trial, and you would be surprised what juries think. > Furthermore, deleting the test case makes no sense as a remedy. Either > there is or there is not a copyright violation. The judge c

Re: how small can gcc get?

* Philip George: > it needs only to be able to compile extremely simple c apps from a > shell opened from within the gui app. Have a look at tcc. It might be more suited to your needs than GCC.

Ada test suite

Some time ago, someone posted a patch which provided beginnings of a general-purpose Ada test suite infrastructure (in addition to the current ACATS tests, which cannot be used for regression tests). The patch was not integrated, and I can't find it at the moment. 8-( Does anybody know which patc

Re: Ada test suite

* Arnaud Charlet: >> Some time ago, someone posted a patch which provided beginnings of a >> general-purpose Ada test suite infrastructure (in addition to the >> current ACATS tests, which cannot be used for regression tests). The > > Note that this is technically incorrect: the ACATS infrastruct

Re: Borland software patent restricting GNU compiler development

* Ingrid Marson: > The Borland patent is a patent for standard exception handling > http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL > &p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=5,628,016.WKU.&OS=PN/5,628, > 016&RS=PN/5,628,016 At least on Linux, GCC implements a differe

Re: Borland software patent restricting GNU compiler development

* Ranjit Mathew: > Without looking at the patent, I would hazard the guess > that it is about Win32 Structured Exception Handling (SEH): > > http://www.microsoft.com/msj/0197/exception/exception.aspx > > (The linked-to mail from the GCC mailing list seems to > confirm this.) Indeed. Explicitly

Re: Borland software patent restricting GNU compiler development

* Paul Koning: >>>>>> "Florian" == Florian Weimer <[EMAIL PROTECTED]> writes: > > Florian> Indeed. Explicitly pushing an exception frame pointer on > Florian> the main stack is covered by the patent. > > Oh, like VMS has done since V

Exporting structure layout

When interfacing with C with other languages, it is often necessary to write wrapper functions to access C structs because there are no general (and free) tools available which can generate structure layout information from C sources. For example, suppose that I want to write Ada code which uses t

Re: Exporting structure layout

* Paolo Bonzini: >> Additional members are permitted, and the fields can be order. In >> order to create a portable Ada interface, I have to write a short C >> program which uses sizeof and offsetof to extract the structure >> layout. In theory, it is possible to create compile-time-only tests >

Re: Exporting structure layout

* Ian Lance Taylor: > I actually have a vague recollection that gcc used to implement > something along these lines, but I couldn't find it in five minutes of > searching. There are several patches for (or forks of) GCC which implement similar functionality.

Re: GCC 4.1: Buildable on GHz machines only?

* Russ Allbery: > Seriously, though, I think the above only tests things out to the degree > that Autoconf would already be warning about no default specified for > cross-compiling, yes? Wouldn't you have to at least cross-compile from a > system with one endianness and int size to a system with

Re: GPU-aware compiling?

* Tomasz Chmielewski: > Well, wouldn't it be a GCC improvement? :) I think it's mostly a GPU issue because GPU implementation details are highly proprietary and usually treated as trade secrets.

Re: Compiling GCC with g++: a report

* Gabriel Dos Reis: > The first resistance seems to come from the pervasive use of the implicit > conversion void* -> T*, mostly with storage allocating functions. This can be worked around on the C++ side, see the example code below. It's a kludge, but it's not too bad IMHO. class xmalloc_resul

Re: Compiling GCC with g++: a report

* Christoph Hellwig: > Why can't libstdc++ use symbol versioning? Via stack allocation, templates and inline functions, the internal representation of libstdc++ data structures is exported. All of its users would have to be versioned, too, and you'd need bridging code between the ABIs (e.g. to p

Re: %dil in x86 inline asm

* Phil Endecott: > I've found bug 10153 and its duplicates which seem to be describing > essentially the same thing, but say that the input is invalid because it > uses "r" rather than "q". I don't know enough about x86 to understand > this; presumably only certain registers can be used with t

Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE? Is it possible to get rid of their effect using a NOP_EXPR, CONVERT_EXPR or VIEW_CONVERT_EXPR? If this is impossible, the Ada front end should probably stop setting these fields because it assumes that it can use values outside that range:

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

* Diego Novillo: >> >> >> Current mainline does not optimize array range checks away (even with >> -ftree-vrp), but I'm not sure if this is just a missed optimization >> opportunity as far as the optimizers are concerne

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

* Richard Kenner: > How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE? Is it possible to > get rid of their effect using a NOP_EXPR, CONVERT_EXPR or > VIEW_CONVERT_EXPR? > > I don't really understand either question. Also, as to the second, > keep in mind their role in array indexes.

Re: configure test for a mmap flag

* Steve Kargl: > I need to add a configure test to determine if MAP_NOSYNC is > present. What about "#ifdef MAP_NOSYNC" in the code? Or do you invoke mmap directly from Fortran?

Re: Ada front-end depends on signed overflow

* Andrew Pinski: > The Ada front-end is still being missed compiled by VRP but VRP is doing > the correct thing as the type is signed and overflow on signed is > undefined > (-fwrapv is not turned on by default for Ada). It probably makes sense to turn on -fwrapv for Ada because even without -gn

Re: Ada front-end depends on signed overflow

* Paul Schlie: >> (Without -fwrapv, integer overflow is undefined, and subsequent range >> checks can be optimized away, so that it might cause erroneous >> behavior.) > > - Since for all practical purposes most (if not all) target's use > 2's complement integer representations which naturally "

Re: Ada front-end depends on signed overflow

* Paul Schlie: >> No they should be using -ftrapv instead which traps on overflow and then >> make sure they are not trapping when testing. > > - why? what language or who's code/target ever expects such a behavior? I think Andrew wants programmers to fix their code, instead of papering over prob

Re: Ada front-end depends on signed overflow

* Joe Buck: > I'm sure there are plenty of production codes that assume signed integer > overflow wraps, or at least make the weaker assumption that in > >a = b + c + d; > > where all variables are integers, if one of the intermediate terms > can't be represented in an integer, we still ge

Re: collab.net have a spam open relay in operation at the moment. please give them grief about it.

>> the collab.net server in question has been utilised to forge messages >> from openoffice.org to [EMAIL PROTECTED], which i am guessing >> is a sf.net internal email-absolutely-everybody mailing list. > > We opened an internal issue at CollabNet to look into this, and found > that we don't have a

Re: Ada front-end depends on signed overflow

* Robert Dewar: > Defintiely not, integer overflow generates async traps on very few > architectures. Certainly synchronous traps can be generated (e.g. > with into on the x86). Or the JO jump instruction. Modern CPUs choke on the INTO instruction.

Re: Ada front-end depends on signed overflow

* Paul Schlie: > - I'm not attempting to design a language, but just defend the statement > that I made earlier; which was in effect that I contest the assertion > that undefined evaluation semantics enable compilers to generate more > efficient useful code by enabling them to arbitrarily de

Re: Ada front-end depends on signed overflow

* Paul Schlie: >> But the assertion is trivially true. If you impose fewer constraints >> on an implementation by leaving some cases undefined, it always has >> got more choices when generating code, and some choices might yield >> better code. So code generation never gets worse. > > - yes, it

Re: strange double comparison results with -O[12] on x86(-32)

* Andrew Pinski: > This is known as GCC PR 323 which is not a bug: > . It is a bug in GCC, the C standard, or the x86 FP hardware. I'm leaning towards the C standard or the hardware. 8-)

Re: strange double comparison results with -O[12] on x86(-32)

* Dave Korn: >> It is a bug in GCC, the C standard, or the x86 FP hardware. I'm >> leaning towards the C standard or the hardware. 8-) > > > ... or it's a bug in the libc/crt-startup, which is where the > hardware rounding mode is (or should be) set up ... I think you'd still experience latent

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

* Daniel Jacobowitz: > How would you feel about a patch that made us always pass --64 > as appropriate, at least if the assembler in question is gas? I > periodically bootstrap on a 64-bit kernel with a 32-bit root FS. But > the assembler and linker are biarch, and the 64-bit libs are installed,

Re: copyright assignment

* James A. Morrison: > The form is here: > http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html > > If you have any questions feel free to ask. It's better to request the current version from the FSF, see:

Re: Reporting bugs: there is nothing to gain in frustrating reporters

* Gabriel Dos Reis: > Scott Robert Ladd <[EMAIL PROTECTED]> writes: > > | Giovanni Bajo wrote: > | > Agreed. But keep in mind that it is not necessary to reply: once the bug > is > | > open and confirmed, the last comment "wins", in a way. If the bugmaster > | > wanted to close it, he would just

Re: basic VRP min/max range overflow question

* Paul Schlie: > So in effect the standard committee have chosen to allow any program which > invokes any undefined behavior to behave arbitrarily without diagnosis? > > This is a good thing? It's the way things are. There isn't a real market for bounds-checking C compilers, for example, which o

Re: Template declaration inside function

* Mattias Karlsson: > Given: > > void f(void) > { >template class A >{ >}; > } > > g++ 4.0/3.4 gives: > bug.cpp:4: error: expected primary-expression before 'template' > > Can a language lawer please confirm that this is even valid before I > create a PR? It's not valid (local templa

Re: signed is undefined and has been since 1992 (in GCC)

* Dave Korn: > It certainly wasn't meant to be. It was meant to be a dispassionate > description of the state of facts. Software that violates the C standard > just *is* "buggy" or "incorrect", Not if a GCC extension makes it legal code. And actually, I believe a GCC extension which basicall

Re: signed is undefined and has been since 1992 (in GCC)

* Robert Dewar: > I am puzzled, why would *ANYONE* who knows C use int > rather than unsigned if they want wrap around semantics? Both OpenSSL and Apache programmers did this, in carefully reviewed code which was written in response to a security report. They simply didn't know that there is a p

Re: signed is undefined and has been since 1992 (in GCC)

* Robert Dewar: > Making programs bug free has more to it than understanding the language > you are writing in, but it is a useful step forward to avoid problems > that come from simply not knowing the rules of the language you are > writing in (I can't guarantee that GNAT is bug free in that rega

Re: Calling a pure virtual function

* Adam Nielsen: > class Base { > public: > Base() > { > cout << "This is class " << this->number(); > } > > virtual int number() = 0; > }; Roughly speaking, when number() is invoked, the object still has type Base (with a corresponding vtable). One's constructor will chan

Re: Calling a pure virtual function

* Adam Nielsen: > It still makes me wonder whether GCC is reporting the correct error for > this mistake though, I would've expected a compiler error (something > along the lines of 'you can't call a pure virtual function') rather than > a linker error. Especially as GCC should be able to tell at

Re: Large, modular C++ application performance ...

* michael meeks: > I've been doing a little thinking about how to improve OO.o startup > performance recently; and - well, relocation processing happens to be > the single, biggest thing that most tools flag. Have you tried prelinking?

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Richard Henderson: > For the record, I believe we've addressed these issues sometime > within the last year or two. The TYPE_MIN/MAX_VALUE for an enum > should be set to the range truely required by the relevant language > standards (different between C and C++). > > I don't know for a fact tha

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Richard Kenner: > This is wrong (as discussed before) and is likely the cause of PR21573 > (not VRP-related, the expanders for SWITCH_EXPR look at these > attributes, too). I'm not sure if it is safe to delete these > assignment statmeents because TYPE_MIN_VALUE/TYPE_MAX_VAL

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Richard Kenner: > No, the language (or, more precisely, GNAT) defines them as 0 and > 2**size - 1. Otherwise the 'Valid attribute doesn't work. Necessary > range checks will be optimized away, too. > > No, enumeration types are defined as having precisely the set of > values spe

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Richard Henderson: > On Fri, Aug 05, 2005 at 10:15:04PM +0200, Florian Weimer wrote: >> TYPE_MIN_VALUE (gnu_scalar_type) >> = gnat_to_gnu (Type_Low_Bound (gnat_entity)); >> TYPE_MAX_VALUE (gnu_scalar_type) >> = gnat_to_gnu (Type_High_Bound (gn

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Richard Kenner: > This is simply not true for Ada. Look at the definition of the 'Valid > attribute in the standard: > >3. X'Valid > > Yields True if and only if the object denoted by X is normal > and has a valid representation. The value of this attribute

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Richard Kenner: > Both ARM 13.9.1 and the GNAT User Guide (in Section 3.2.4 Validity > Checking) require that such reads are NOT erroneous. > > It depends what "such reads" mean. 13.9.1(12) clearly says that the > result of an Unchecked_Conversion is erroneous if it isn't a valid > re

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Robert Dewar: > Florian Weimer wrote: >> If this still doesn't convince you, here's an example which doesn't >> use Ada.Unchecked_Conversion at all. > > this example must print Success, that is guaranteed by the RM Yes, I think so. What about the f

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Robert Dewar: > Florian Weimer wrote: > >> I fear that such barriers are also needed for all checks on scalars, >> by the way, not just 'Valid. > > indded, and we do unchecked conversions to the base type in these > cases. i guess we could fix the enum case by

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Richard Kenner: > If this still doesn't convince you, here's an example which doesn't > use Ada.Unchecked_Conversion at all. > > Well sure, reading an uninitialized value is erroneous except for the use > of 'Valid. No, it's not, as Ada is not C. And please not the presence of pragma N

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Richard Kenner: > > Well sure, reading an uninitialized value is erroneous except for the > use > > of 'Valid. > > No, it's not, as Ada is not C. > > What's "not"? My statement is based on the Ada RM. Quote from section 13.9.1 follows. Note the "but does not by itself lead to e

Re: PR 23046. Folding predicates involving TYPE_MAX_VALUE/TYPE_MIN_VALUE (Ada RFC)

* Laurent GUERBY: > An implementation model could be for the front-end to generate for each > family of scalar type T a function Base_Type_Internal_Valid (X, Min, > Max : in Base_Type_Of_T) return Boolean, generate a call to it at all > 'Valid uses and then tell the compiler to never do any inlini

Re: [PATCH]: Proof-of-concept for dynamic format checking

* Ian Lance Taylor: > I haven't tried to flesh this out any further. I'd be curious to hear > how people react to it. Can't we just use some inline function written in plain C to check the arguments and execute it at compile time using constant folding etc.?

Re: [PATCH]: Proof-of-concept for dynamic format checking

* Ian Lance Taylor: > Florian Weimer <[EMAIL PROTECTED]> writes: > >> * Ian Lance Taylor: >> >> > I haven't tried to flesh this out any further. I'd be curious to hear >> > how people react to it. >> >> Can't we just use

Re: [PATCH]: Proof-of-concept for dynamic format checking

* Ian Lance Taylor: > Florian Weimer <[EMAIL PROTECTED]> writes: > >> If I understand your %A/%B example correctly, it would look like this: > > OK, I can see how that might work in a simple case. Now, can you give > me an example of matching %d with the various flags

Re: [PATCH]: Proof-of-concept for dynamic format checking

* Giovanni Bajo: > Do we have a sane way to (partially) execute optimizers at -O0 > without screwing up with the pass manager too much? Do we have to provide user-defined format string warnings at -O0?

Re: [PATCH]: Proof-of-concept for dynamic format checking

* Dave Korn: > PMFBI, but how is all this going to work on a cross compiler? Constant folding works in a cross-compiler, too. 8-)

Re: please update the gcj main page

* Gerald Pfeifer: > On Sun, 31 Jul 2005, Daniel Berlin wrote: >> For code. >> I have never seen such claims made for documentation, since it's much >> easier to remove and deal with infringing docs than code. > > I have seen such statements, by RMS himself. The official position might have change

Re: [GCC 4.x][AMD64 ABI] variadic function

* Matteo Emanuele: > Is it possible to find the register save area and the > overflowing arguments within the called function > without using %ebp (that means with > -fomit-frame-pointer set) and knowing nothing of the > caller? You mean, if the caller called the function as it were a non-variad

Re: 4.2 Project: "@file" support

* Andi Kleen: > Linux has a similar limit which comes from the OS (normally around 32k) > So it would be useful there for extreme cases too. IIRC, FreeBSD has a rather low limit, too. And there were discussions about command line length problems in the GCC build process on VMS.

Re: RFC: bug in combine

* Dale Johannesen: > The test of f->b comes out as > > testl $1048512, 73(%eax) > > This is wrong, because 4 bytes starting at 73 goes outside the > original object and can cause a page fault. sizeof (struct Flags) is 76, so this isn't a bug, IMHO.

Re: RFC: bug in combine

* Florian Weimer: > * Dale Johannesen: > >> The test of f->b comes out as >> >> testl $1048512, 73(%eax) >> >> This is wrong, because 4 bytes starting at 73 goes outside the >> original object and can cause a page fault. > > sizeof (struct Fla

Re: Warning C vs C++

* Tommy Vercetti: >> The warning is controlled by -Wsign-compare, which is turned on by >> -Wextra (also known as -W) but not by -Wall. It's not turned on by >> -Wall because it is not normally a problem. > That's strange, all users I know expected it to turn ALL warnings, > hence name. Some pe

Re: pointer checking run time code

* Robert Dewar: > shreyas krishnan wrote: > >> Ideas, other pointers would be great > > Note that of course this kind of check is standard in Ada > and hence in GNAT, so you can get an idea from GNAT > generated code how well the backend can eliminate > such checks (answer: getting better with gcc

Re: Undefined behavior in genautomata.c?

* Sebastian Pop: > By the way, how is this different than detecting a bound on: > > { > int foo[1335]; > > for (i = 0; i < some_param; i++) > foo[i]; > } > > vs. > > { > some_struct{ int foo[1335];} s; > > for (i = 0; i < some_param; i++) > s.foo[i]; > } Nothing. But in the genau

Re: Final Subversion testing this week

* Daniel Berlin: >> Is it okay to make an unreviewed test commit? > Uh, commit all you want. Permissions don't seem to be set correctly: SendingChangeLog Sendinglibgcc2.h Transmitting file data ..svn: Commit failed (details follow): svn: Can't create directory '/svn/gcc/db/trans

Re: error: forward declaration of `struct bit::bitObject'

* Roel Bindels: > I posted this question on the GCC-help list but maybe someone here > can give me some advice on how to proceed also. The advice you'll get here is exactly the same: post a small example which reproduces the error message which troubles you. (Please continue the discussion on gc

Re: Moving to subversion?

* Steve Kargl: >> Uh, since it appears you are logged in with a different name, you want >> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk > > Odd, I don't need to do anything special with cvs. Once you've checked out a tree, CVS stores the remote user in the CVS/Root file. Maybe you have only

Re: using multiple trees with subversion

* François-Xavier Coudert: > Having 5 subversion trees will need much more space (for local > pristine copies), which I don't really have. Is there any way to force > subversion use one pristine tree for all modified trees, or is my way > of handling things completely rotten? You could try svk, i

Re: RFC: future gfortran development and subversion

* Daniel Berlin: > You could simply do non-recursive checkouts (svn co -N) of the dirs you > want. > SVN doesn't care how you piece together the working copy. Doesn't "commit -N" cause the working copy to become fragmented, so that you cannot issue a working-copy-wide commit or diff anymore?

Re: RFC: IPO optimization framework for GCC

* Sebastian Pop: > Steve Ellcey wrote: >> >> In the meantime I would be interested in any opinions people have on >> what level we should be writing things out at. Generic? Gimple? RTL? > > Or just dumping plain C code? This is almost what the pretty printers > are doing, and the way back to

Re: backslash whitespace newline

* Mike Stump: > On Oct 24, 2005, at 5:52 PM, Vincent Lefevre wrote: >> But then, copy-paste would no longer always work since spaces are >> sometimes added at the end of some lines (depending on the terminal >> and the context). > > Please name such systems. We can then know to not use them, and

Re: Question on proposed use of "svn switch"

* Richard Kenner: > Here's what I need to do and I welcome suggestions: one of the working > directories I have is the FSF GCC repository (from HEAD), but the > gcc/ada subdirectory is the AdaCore repository. For cvs, what I do in > gcc/CVS/Entries is delete the line for "ada" and then checkout t

Re: backslash whitespace newline

* Mike Stump: > On Oct 24, 2005, at 10:39 PM, Florian Weimer wrote: >> Emacs in an xterm, from time to time. > > Yeah, I knew about that one, cutting and pasting from any full screen > program running in a terminal emulator tends to be wrong. Tab > characters

Re: Revisiting generalized lvalues

* Michael Krasnik: > #ifdef PRODUCTION > #define X_ABC(x) ( check( x ), x->abc ) > #else > #define X_ABC(x)x->abc > #endif > > which expands > > X_ABC(x) = y; > > to: > > ( check( x ), x->abc ) = y; > Eliminating this construct makes macros much less flexible > and requires

Re: Update on GCC moving to svn

* Joe Buck: > Well, maybe. But what about a revision that modifies code and that > also modifies the WWW to describe the code modification? If everything > were in the same subversion repository, it could be one change. Only if you check out a common parent directory, which is probably not a co

Re: GPL question

* dfhgjwetgtry: > If I compile source code using GCC, that does not require me to > open-source the resulting program under the GPL, correct? Compiling a program with GCC does not by itself cause the resulting executable to be covered by the GNU General Public License. This does not however inva

Re: insufficient inline optimisation?

* Steven Bosscher: >> I think that the optimiser should get rid of the loop once it has got >> rid of >> the body! > I don't think so.  This kind of thing is optimized away by gcc 4.1 > already. Shouldn't this be listed in the changes.html file?

  1   2   3   4   5   6   7   8   >