Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> your corresponding supporting standard citation to the contrary? > > C99 3.17.2 defines "indeterminate value" as "either an unspecified > value or a trap representation". 6.2.6.1p5 says of trap > representations: "If the stored value

Re: Signed int overflow behavior in the security context

> Paul Jarc wrote: >> Paul Schlie <[EMAIL PROTECTED]> wrote: >> your corresponding supporting standard citation to the contrary? > > C99 3.17.2 defines "indeterminate value" as "either an unspecified > value or a trap representation". 6.2.6.1p5 says of trap > representations: "If the stored value

build failure, gcc-4.3-20070126 snapshot, cygwin

[ -f stage_final ] || echo stage3 > stage_final make[1]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo' make[2]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo' make[3]: Entering directory `/cygdrive/d/src/gcc/gcc-4.3-20070126/yo' rm -f stage_current make[3]: Leaving dir

Re: Signed int overflow behavior in the security context

Paul Schlie <[EMAIL PROTECTED]> wrote: > your corresponding supporting standard citation to the contrary? C99 3.17.2 defines "indeterminate value" as "either an unspecified value or a trap representation". 6.2.6.1p5 says of trap representations: "If the stored value of an object has such a repres

Re: Signed int overflow behavior in the security context

> Paul Schlie wrote: >>> Brooks Moses wrote: >>> ... >>> Does that logic work for you? >> >> no, as although a variable's value may not have been previously defined >> within the context of a particular program, a variable's access semantics >> are

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: >> Brooks Moses wrote: >> ... >> Does that logic work for you? > > no, as although a variable's value may not have been previously defined > within the context of a particular program, a variable's access semantics > are orthogon

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote: >> Paul Schlie wrote: >>> Brooks Moses wrote: >>> ... >>> Does that logic work for you? >> >> no, as although a variable's value may not have been previously defined >> within the context of a particular program, a variable's

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: Brooks Moses wrote: ... Does that logic work for you? no, as although a variable's value may not have been previously defined within the context of a particular program, a variable's access semantics are orthogonal to what eve

Re: Signed int overflow behavior in the security context

Brooks Moses wrote: I think you and Robert may be talking about different contexts. I'm pretty sure (though not positive) that Robert is talking about the case after an undefined operation has occurred. I'm not sure if you're talking about that, or talking about normal program operation. I

Re: Signed int overflow behavior in the security context

> Brooks Moses wrote: > ... > Does that logic work for you? no, as although a variable's value may not have been previously defined within the context of a particular program, a variable's access semantics are orthogonal to what ever value may resu

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: I'm game; how might multiple specified references to the same non-volatileS variable with no specified intervening assignments in a single threaded language ever justifiably be interpreted to validly yield differing values? Sorry, I'm not "game", it's something you should be

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: Robert Dewar wrote Paul Schlie wrote: - However x ^= x :: 0 for example is well defined because absent any intervening assignments, all reference to x must semantically yield the same value, regardless of what that value may be. Nope, there is no such requirement in the sta

Re: Signed int overflow behavior in the security context

> Robert Dewar wrote >> Paul Schlie wrote: >> - However x ^= x :: 0 for example is well defined because absent any >> intervening assignments, all reference to x must semantically yield the >> same value, regardless of what that value may be. > > Nope, there is no such requirement in the standard

Re: Signed int overflow behavior in the security context

Paul Schlie wrote: - However x ^= x :: 0 for example is well defined because absent any intervening assignments, all reference to x must semantically yield the same value, regardless of what that value may be. Nope, there is no such requirement in the standard. Undefined means undefined. Agai

GCC 4.2 Release notes are almost empty

Well, not really. But there are a lot of new features and important things missing. And it should be responsibility of whoever added the new feature to document it, shouldn't it? So now that we are in the late phase of stage3, it could be a good moment. Martin Michlmayr listed some things that ma

Re: How to enforce the use of libjava/scripts/jar?

On Sun, 21 Jan 2007, Tom Tromey wrote: > I think we should never install the jar script -- we now have a gjar > tool from Classpath which we can use. On svn trunk we do build and > install this, for native systems (I think to avoid mixing host and > target executables in bindir). I think we shoul

Re: G++ OpenMP implementation uses TREE_COMPLEXITY?!?!

On 1/28/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: Hello rth, Can you explain what went through your mind when you picked the tree_exp.complexity field for something implemented new... :-( Not much... http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01117.html "... but my brain isn't workin

Re: Ada and the TREE_COMPLEXITY field on struct tree_exp

On 1/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote: > I had thought of a hash table, too, but I couldn't figure out where to > initialize and free it (i.e. where it is a "live" table, so to speak). For > example, I don't know if this table would be required after gimplification, > and I also d

G++ OpenMP implementation uses TREE_COMPLEXITY?!?!

Hello rth, Can you explain what went through your mind when you picked the tree_exp.complexity field for something implemented new... :-( You know (or so I assume) this was a very Very VERY BAD thing to do, if we are ever going to get rid of TREE_COMPLEXITY, which is a major memory hog. We are

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

Ray Hurst wrote: By the way, was this the correct place to post it? Ray Two very senior GCC developers have already answered your question in the same manner. If you review what they said, you will see that the answer is *no*. David Daney

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

Ray Hurst wrote on 01/27/07 16:48: I think this was the answer I was looking for. By the way, was this the correct place to post it? No. That was a language question. gcc-help or comp.std.c++ would have been a better forum. This deals with the development of GCC, not its use.

Re: How to enforce the use of libjava/scripts/jar?

On Mon, 22 Jan 2007, Andreas Schwab wrote: >> My question now is: Is there any way to enforce the use and installation >> of our own copy of ${PREFIX}/bin/jar${PROGRAMSUFFIX}? > Set JAR to no before configuring. Works like a charm. Thanks for the hint, Andreas! Gerald

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

I think this was the answer I was looking for. By the way, was this the correct place to post it? Ray Ferad Zyulkyarov wrote: Hi, If you want to phrase the question in terms of object file format and linker issues, the answer is that the format is the same. It's easy to see why: the compiler

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

Hi, If you want to phrase the question in terms of object file format and linker issues, the answer is that the format is the same. It's easy to see why: the compiler does not produce object files. It produces files containing assembly language. The assembler produces object files. The C and

GCC-4.0.4

Please consider the GCC-4.0.4 as frozen. No non-documentation check-in is permitted. For documentation check-in, please consult with me first. Thanks, -- Gaby

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

Top level libgcc migration tips

I've put up some information on the wiki about moving configuration information from gcc to libgcc. Please, feel free to add to it! http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration -- Daniel Jacobowitz CodeSourcery

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

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. Ray Joe Buck wrote: On Fri, Jan 26, 2007 at 04:25:54P

Signed int overflow behavior in the security context

> Richard Guenther wrote: > On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> wrote: On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: >>> Likewise, if the program has an uninitialized variable, the behavior >>> will differ depending on details of optimization and how variables are >>> as

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: Signed int overflow behavior in the security context

On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> wrote: >> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote: > Likewise, if the program has an uninitialized variable, the behavior > will differ depending on details of optimization and how variables are > assigned to memory. Heap allocated

Re: Signed int overflow behaviour in the security context

> I'm exactly talking about the semantics of "undefined" here. It would > be immensely reassuring if a compiler would at least interpret this as > "unspecified, but consistent". Even better would be a defined and > documented semantics for everything left undefined by the standard. Are you propo

Re: Signed int overflow behaviour in the security context

> While there are programmers out there where any attempt at getting them > to write even remotely secure software, most of them can be taught the > concept of LIA-1 semantics, and a lot of them already know and write > software accordingly. Getting them to understand that an expression > like "if

Re: Signed int overflow behaviour in the security context

On Sat, 2007-01-27 at 02:47 +0100, Andreas Bogk wrote: > I'm exactly talking about the semantics of "undefined" here. It would > be immensely reassuring if a compiler would at least interpret this as > "unspecified, but consistent". Even better would be a defined and > documented semantics for