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
Paul Schlie <[EMAIL PROTECTED]> wrote:
> if it has an indeterminate value [...] has no bearing on an rvalue
> access to a well defined storage location
You might think so, but that's actually not true in the C standard's
terminology. It sounds like you interpret "indeterminate value" to
mean what
Paul Schlie <[EMAIL PROTECTED]> wrote:
> x = x ; perfectly fine; as lvaue x clearly designates an object (no trap)
Can you cite the part of the standard that says that? The fact that
an expression designates an object does not exclude that object from
holding a trap representation. A trap repre
Paul Schlie <[EMAIL PROTECTED]> wrote:
> One can only hope that the recommendations won't see the light of day in
> their present form, as it's fairly clear that once an unspecified value is
> read (presuming absents of a trap representation), it becomes logically
> visible, and thereby clearly no
Paul Schlie <[EMAIL PROTECTED]> wrote:
> Paul Jarc wrote:
>> As noted in the defect report, a trap representation can have the
>> same bit pattern as a valid value. Trapness depends not just on
>> the bit pattern, but also how the bit pattern was produced.
>
> -
gcc/doc/install.texi still mentions gcc 3.5 in a few places.
paul
Sorry to bring this up so late, but I just tried building the last
4.2.0 prerelease and hit what seems to be a build bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31906
paul
Joe Buck <[EMAIL PROTECTED]> wrote:
> I don't even think this qualifies as a bug. It's basically an
> enhancement request, to have a clean way of supporting glibc in
> an unusual place.
It works in previous versions going back to 2.95.3, so I'd think it
would be a bug, and a regression. But sinc
Joe Buck <[EMAIL PROTECTED]> wrote:
> But this was never a documented, supported way of doing things;
> nothing that involves hand-editing could be.
Fair enough, as far as my particular case is concerned. But something
new in 4.2 is inserting "-Xcompiler" between "-Xlinker" and the
following argu
"YaniMan" <[EMAIL PROTECTED]> wrote:
> Or these messages should going (by an option) to the stdout rather than
> stderr, so i can write a parser (gcc a.c | myparser) to convert the
> messages.
gcc a.c 2>&1 | myparser >&2
paul
Rainer Emrich <[EMAIL PROTECTED]> wrote:
> So I wan't to pass LDFLAGS="-Wl, -rpath, /somedir" to stage3 to link gcc, cpp,
> etc. with the rpath information.
I do this by editing LDFLAGS_FOR_TARGET in the top-level Makefile.in,
and also passing LDFLAGS, BOOT_LDFLAGS, and HOST_LDFLAGS assignments
as
To find gcc's installation prefix, I've been using
"gcc -print-search-dirs". That worked up until 4.3, but now gcc
chases symlinks so it can print symlink-free paths. What I want is
the installation path just as it was spelled in
"./configure --prefix=...". In my case, that spelling is an absolu
Jack Howarth wrote:
> make -j 8 profiledbootstrap BOOT_CFLAGS="-g -O3"
>
> I noticed the absence of these flags being utilized in libdecnumber,
> libffi, libgcc, etc.
On a related note, how can I pass *linker* flags for linking libgcc?
I've passed --with-stage1-ldflags and --with-boot-ldflags to
Ian Lance Taylor wrote:
> LDFLAGS_FOR_TARGET is the one that should be used. However, you're
> right that it doesn't appear to happen. This is a bug.
...
> I think you need to edit the file gcc/config/t-slibgcc-elf-ver.
Thanks--adding $(LDFLAGS_FOR_TARGET) to SHLIB_LINK in that file seems
to wo
14 matches
Mail list logo
