"Kaveh R. GHAZI" writes:
> On Fri, 10 Apr 2009, Ian Lance Taylor wrote:
>
>> Add a new shell variable in configure.ac extra_mpfr_configure_args. Set
>> it to what you want to pass to the mpfr configure. Call
>> AC_SUBST(extra_mpfr_configure_args). In Makefile.in add a line
>> EXTRA_MPFR_CONFIG
On Fri, 10 Apr 2009, Ian Lance Taylor wrote:
> Add a new shell variable in configure.ac extra_mpfr_configure_args. Set
> it to what you want to pass to the mpfr configure. Call
> AC_SUBST(extra_mpfr_configure_args). In Makefile.in add a line
> EXTRA_MPFR_CONFIGURE_ARGS = @extra_mpfr_configure_a
To all, I stand abashed - don't try this without a trained instructor. I
misread the Schildt quote and (I think) wasted your time(s).
Thank you
art
--- On Fri, 4/10/09, David Fang wrote:
> From: David Fang
> Subject: Re: operator=() issue
> To: "Arthur Schwarz"
> Cc: gcc@gcc.gnu.org
> Date
One more thing to add ...
Program 1 fails
# include
using namespace std;
class thing : private ios_base {
ostream& xo;
public:
thing(ostream& y) : xo(y) { xo = y; }
};
gcc.3.4.4 messaging
x.cpp: In member function `std::basic_ios >&
std::basic_ios >::operator=(const
std::basic_ios >&
On Fri, Apr 10, 2009 at 05:28:50PM -0700, Arthur Schwarz wrote:
>
> You understood me correctly. My (mis?)understanding comes from:
>
> The Complete Reference,Fourth Edition
> Herbert Schildt
> Copyright 2003
> ISBN 0-07-222680-3
gcc doesn't implement Schildt's book, it aims to implement
Arthur Schwarz writes:
> "Remember: When a base class' access specifier is private, public and
> protected members of the base become private members of the derived
> class. This means that they are still accessible by members of the
> derived class but cannot be accessed by parts of your program
Stelian Pop wrote:
>>> Do I need to define movsi3(), addsi3() etc. patterns manually or should GCC
>>> figure those by itself ?
>> Not sure I understand you. You always need to define movMM3 etc. GCC will
>> correctly select between movhi3 and movsi3 based on your Pmode macro when
>> handling
You understood me correctly. My (mis?)understanding comes from:
The Complete Reference,Fourth Edition
Herbert Schildt
Copyright 2003
ISBN 0-07-222680-3
Page 420 (And I Quote - don't you just love the phrase)
"Remember: When a base class' access specifier is private, public and protect
operator=() is private in ios_base. Using private inheritance of
ios_base the program below fails in the constructor when '=' is used
(but not during memory initialization). I don't understand why
assignment is prohibited.
art
Program 1 fails
# include
using namespace std;
class thing : pr
Arthur Schwarz writes:
> operator=() is private in ios_base. Using private inheritance of
> ios_base the program below fails in the constructor when '=' is used
> (but not during memory initialization). I don't understand why
> assignment is prohibited.
Perhaps I misunderstand your question, but
operator=() is private in ios_base. Using private inheritance of ios_base the
program below fails in the constructor when '=' is used (but not during memory
initialization). I don't understand why assignment is prohibited.
art
Program 1 fails
# include
using namespace std;
class thing : pri
Chris Lattner wrote:
On Apr 10, 2009, at 1:55 PM, Jason Merrill wrote:
My impression is that the C++ committee generally feel that exception
specifications are a failed feature, and nobody is particularly
interested in fixing them.
Have you seen this?
http://www.open-std.org/JTC1/SC22/WG21/do
On Apr 10, 2009, at 1:55 PM, Jason Merrill wrote:
My impression is that the C++ committee generally feel that
exception specifications are a failed feature, and nobody is
particularly interested in fixing them.
Hi Jason,
Have you seen this?
http://www.open-std.org/JTC1/SC22/WG21/docs/papers
Simon Hill wrote:
C) Lastly, it would be nice if someone could indicate whether a
finished and fully functional version of this project would be likely
to make it into the mainline as I have seen requests for its
functionality many times, including on this mailing list, and it has
no downside:
-
Arthur Schwarz writes:
> # include
> # include
>
> using namespace std;
>
> ifstream x;
> ifstream& y = x;
>
> int main(int argc, char** argv) {
> y = x;
> return 0;
> }
>
> g++.3.4.4 output
> m1.cpp: In member function `std::basic_ios >&
> std::basic_ios >::operator=(const
> std::basic_
On Fri, Apr 10, 2009 at 06:29:06PM +0100, Dave Korn wrote:
> Stelian Pop wrote:
> > Hi,
> >
> > I'm (still) porting GCC to a 16 bit microcontroller, and I'm having a few
> > issues with the way it handles memory accesses: this microcontroller can
> > function in two modes: in one of them the poin
(This question probably should be on gcc-help instead of this list.)
> I'm trying to redirect I/O in my C++ application and am having some
> difficulty. I am trying to use cout or a file for output based on some
> condition. cout is an ostream object and file is an ofstream object.
> The types are
On Fri, 10 Apr 2009, Steve Ellcey wrote:
> $ cat x.c
> typedef unsigned char uint8_t;
> void test_exact (void)
> {
> __typeof__(((255u))) a;
> __typeof__((uint8_t)0 + 0) *b = &a;
> }
>
> $ gcc -std=iso9899:1999 -pedantic-errors -fhosted -c x.c
> x.c: In function 'test_exact':
> x.c:5: error:
This isn't a compiler question and I apologize for that. I'm having a devil of
a time getting an answer to my issues on the C/C++ forums I'm using and, sigh,
perhaps someone can direct me to a forum where the questions can be better
addressed.
I'm trying to redirect I/O in my C++ application a
"Kaveh R. GHAZI" writes:
> What I would like to see is that the extra_configure_flags for mpfr
> actually check whether gmp is being built in-tree before passing
> --with-gmp-build=foo to mpfr's configure. But I don't get how to do that.
> If the mpfr case could be fixed, I could then copy the m
Arthur Schwarz wrote:
> /*
> * m3.cpp
> */
>
> # include
> # include
>
> using namespace std;
>
> ifstream x;
> ifstream y();
> If 'std::ifstream' not found, why is 'std::ifstream y();' legal?
Ooh, I know this one. It's because it's not a definition of an ifstream
object constructed
I am working on changing GCC for HP-UX to use the 'wrap' method for stdint
and doing the fixincludes work to make the system header more c99 compliant
and see if I can get the various c99-stdint-*.c tests to pass.
I have made some good progress but am currently running into this problem
cutdown f
Stelian Pop wrote:
> Hi,
>
> I'm (still) porting GCC to a 16 bit microcontroller, and I'm having a few
> issues with the way it handles memory accesses: this microcontroller can
> function in two modes: in one of them the pointers are on 16 bit (a full
> register), in the second one the pointers a
I'm seeing an issue with the top level configure code. Looking at it
requires juggling m4, guile, shell and make syntax in one's head, I'm
having some trouble so I'm seeking some assistance.
I'm running into the actual problem when I'm integrating the mpc library
with GCC and testing in-tree buil
For two testresults now the cleanup tests are failing in both gcc and g++:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01031.html
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00592.html
I waited for another testresults because there were some bug fixes in this
area after the eh chang
In light of the foolhardy commitment I made, here are some reprehensible
diagnostic messages and the superb recanting of the obvious. As always, the
messaging and comments are gratuitously provided and I hope accepted in the
same manner.
Two notes (made before):
1: Some messages are needlessl
Hi,
I'm (still) porting GCC to a 16 bit microcontroller, and I'm having a few issues
with the way it handles memory accesses: this microcontroller can function in
two modes: in one of them the pointers are on 16 bit (a full register), in the
second one the pointers are on 32 bit and are stored in
"Blower, Melanie" writes:
> I am an employee of Intel Corp. who will be making future
> contributions to gcc, binutils, gdb and glibc. I am writing to request
> copyright assignment forms, and other legal forms that are deemed
> necessary by FSF, which will enable me to contribute to gcc, binutil
Is this possible by any supported mechanism we currently have in the gcc
build system?
I want to add "-Wl,-stack,0x800" to the link flags when building jc1, on
Cygwin only. Can I just do something like this
jc1$(exeext) : LDFLAGS += -Wl,-stack,0x800
in a tm frag and expect it to b
TWIMC
I am an employee of Intel Corp. who will be making future contributions to gcc,
binutils, gdb and glibc. I am writing to request copyright assignment forms,
and other legal forms that are deemed necessary by FSF, which will enable me to
contribute to gcc, binutils, gdb and glibc.
Thank
Am Freitag, den 10.04.2009, 09:22 +0200 schrieb Richard Guenther:
> On Fri, Apr 10, 2009 at 3:41 AM, Ian Lance Taylor wrote:
> > John Engelhart writes:
> >
> >> The easiest, and I think safest, course of action would be to add a
> >> line in c_common_get_alias_set similar to the one I suggested.
Dave Korn wrote:
Robert Dewar wrote:
The compiler
should not assume validity unless it can prove that the value is
actually in the declared range in my opinion.
We could add a "-fstrict-validity=" by analogy to "-fstrict-alias=". Ada
and C would want to have different default settings I im
On Fri, Apr 10, 2009 at 12:03 AM, Eric Botcazou wrote:
> Hi,
>
> we're almost ready to get rid of the awkward semantics that is implemented in
> the middle-end and the optimizers for subtypes (INTEGER_TYPEs with a non-null
> TREE_TYPE); this should overall simplify things, make the support for inv
On Fri, Apr 10, 2009 at 3:41 AM, Ian Lance Taylor wrote:
> John Engelhart writes:
>
>> The easiest, and I think safest, course of action would be to add a
>> line in c_common_get_alias_set similar to the one I suggested. That
>> is, if it is a pointer to something that looks even remotely like a
34 matches
Mail list logo
