Re: Fwd: Objective-C and C99 strict aliasing
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 an >> objective-c "object", then just assume that it can alias anything. >> >> Any recommendations on what to do next? Filing a bug seems like the >> step, I just wanted to see if I had missed something in my analysis of >> the problem. > > Since you have a patch, you can just send it to gcc-patc...@gcc.gnu.org > with a ChangeLog entry (see many existing messages on gcc-patches). It > would be very good if you also had a test case to add to the testsuite. Note that I think that ObjC should be fine (assuming it is a completely statically typed language) if it properly maintains BINFO records. At least this is how it works in C++, see record_component_aliases in alias.c. If ObjC is really dynamically typed then TBAA is indeed doomed. Richard.
Re: [RFC] Get rid of awkward semantics for subtypes
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 invalid > values in Ada more robust and expose more optimization opportunities. > > Patches have already been written and tested (I've attached the non-gigi part > we currently use, preparatory patches are required for gigi first). All the > subtypes are given maximal bounds for their precision, except for TYPE_DOMAIN > of array types like in C, and thus become first class citizens. This makes > it possible to eliminate code in gigi, the gimplifier, the loop optimizer, > the VRP pass, etc. needed to specifically support their special semantics. > > This in turn means that the gimplification will eliminate most of the casts > between subtypes and base types, making the optimizers more effective. The > exception will be the VRP pass, most notably when checks are off in Ada, so > we'll need to be able to drive VRP differently from gigi. I wonder what this exception in VRP looks like? I also wonder if adding a test to the gimplifier that all integral typed DECL types have NULL TREE_TYPE and TYPE_MIN/MAX_VALUE according to their TYPE_PRECISION would pass with your changes (there may be such odd cases with other frontends ...). Thanks for this work - in general I support this (well, you know that ;)). Richard. > > Comments/suggestions welcome. > > > * fold-const.c (fold_truth_not_expr) : Do not strip > it if the destination type is boolean. > * tree-chrec.c (avoid_arithmetics_in_type_p): Delete. > (convert_affine_scev): Remove call to above function. > (chrec_convert_aggressive): Likewise. > * tree-scalar-evolution.c (follow_ssa_edge_expr) : > Propagate the type of the first operand. > (follow_ssa_edge_in_rhs) : Likewise > * tree-ssa.c (useless_type_conversion_p_1): Do not specifically return > false for conversions involving subtypes. > * tree-vrp.c (vrp_val_max): Do not get to the base type. > (vrp_val_min): Likewise. > (needs_overflow_infinity): Do not special-case subtypes. > (extract_range_from_unary_expr): Do not use the base types. > > > -- > Eric Botcazou >
Re: [RFC] Get rid of awkward semantics for subtypes
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 imagine. Well I don't think C has this issue, since it does not have subtype ranges??? Anyway I would not object to such a switch, providing that the default is -fno-strict-validity! cheers, DaveK
Re: Fwd: Objective-C and C99 strict aliasing
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. That > >> is, if it is a pointer to something that looks even remotely like an > >> objective-c "object", then just assume that it can alias anything. > >> > >> Any recommendations on what to do next? Filing a bug seems like the > >> step, I just wanted to see if I had missed something in my analysis of > >> the problem. > > > > Since you have a patch, you can just send it to gcc-patc...@gcc.gnu.org > > with a ChangeLog entry (see many existing messages on gcc-patches). It > > would be very good if you also had a test case to add to the testsuite. > > Note that I think that ObjC should be fine (assuming it is a completely > statically typed language) if it properly maintains BINFO records. At least > this is how it works in C++, see record_component_aliases in alias.c. > > If ObjC is really dynamically typed then TBAA is indeed doomed. ObjC is a dynamically typed language with many design / implementation patterns relying on dynamic typing (NSProxy, NSDistantObject, EOFault just to name a few). Also the language the @defs construct to allow access to the underlying structure to allow certain efficient implementations. Also when implementing class clusters, casting is often used to access instance variables of objects that are assumed to have a certain layout due to certain dynamic predicates. I think most ObjC projects currently use --no-strict-aliasing by default (I know GNUstep related projects do). But it would be great if that could be dropped so that plain C code could take advantage of the potential optimizations, yet I have no real concept of whether any performance gain would be measurable within ObjC itself. Cheers, David
request for legal forms for copyright assignment
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. Thanks and best regards, Melanie Blower (p.s. I'm resending this because the first message was sent in html, sorry if you received a duplicate request) BTW I have 2 colleagues in the same position of needing assignment forms from FSF. Do you prefer to hear from them directly or may I pass along the forms to them after I receive from you? Cf: The FSF prefers that a contributor files a copyright assignment for large contributions. See some documentation by the FSF for details and contact us (either via the gcc@gcc.gnu.org list or the GCC maintainer that is taking care of your contributions) to obtain the relevant forms. The most common forms are an assignment for a specific change, an assignment for all future changes, and an employer disclaimer, if an employer or school owns work created by the developer. It's a good idea to send assignme...@gnu.org a copy of your request. I
Target-dependent, language dependent LDFLAGS during build?
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 be reliable? cheers, DaveK
Re: request for legal forms for copyright assignment
"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, binutils, > gdb and glibc. I sent the request for assignment form off list. Ian
question on 16 bit registers with 32 bit pointers
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 two following registers (N and N+1). I did implement a GCC option to select between the two modes, and I'm using this option to select the size of the pointers and Pmode: #define Pmode ((TARGET_16) ? HImode : SImode) #define POINTER_SIZE((TARGET_16) ? 16 : 32) Do I need to define movsi3(), addsi3() etc. patterns manually or should GCC figure those by itself ? Is there something special I need to do to express the relationship between the two registers N and N+1 composing a pointer, or does GCC automatically allocate two subsequent HI registers when it needs a SI one ? Thanks. -- Stelian Pop
Possible messaging changes
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 needlessly garrulous. You have noted this previously.
2: The length of some diagnostic messages extend beyond reason. You have
noted this previously.
3: In a general environment with many classes, structures, typedef's, etc.
the clear association of a diagnostic message with the offending object,
type, etc. ads clarity. The messages included below have no clear
association (although we might argue that garrulity adds clarity).
4: Code is not self-documenting, sic COBOL, and diagnostic messages aren't
either. A document with messaging guidelines, message descriptions, or
anything else might be useful. Sigh, I can probably help with this.
As a suggestion, since all headers (and included symbols) are known prior to
compilation it might be possible to put all the 'names' into a symbol table for
use during error generation. This allows gcc to (perhaps) publish candidate
solutions when type errors are detected (see m3).
As (yet another) suggestion, since user headers can be processed independently
of code (without considering edge conditions) ya' might as well augment the
first suggestion with user symbols.
And yet again, while processing a given code file, symbols contained in the
code file can be used to (yet again) augment the symbol table for use in
diagnostic generation.
And NOW for the failures!
/*
* m1.cpp
*/
# 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_ios >&)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ios_base.h:784: error:
`std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
m1.cpp:10: error: within this context
m1.cpp: In member function `std::basic_filebuf >&
std::basic_filebuf >::operator=(const
std::basic_fil
ebuf >&)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/streambuf:776: error:
`std::basic_streambuf<_CharT, _Traits>& std::basic_streambuf<_CharT,
_Traits>::operator=(con
st std::basic_streambuf<_CharT, _Traits>&) [with _CharT = char, _Traits =
std::char_traits]' is private
m1.cpp:10: error: within this context
Almost indecipherable. The error is that operator=() is private.
"error: assignment illegal, operator '=' private in ifstream"
/*
* m2.cpp
*/
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
g++.3.4.4 output
m2.cpp:4: error: `ifstream' does not name a type
m2.cpp:5: error: `ifstream' does not name a type
Succint and clear message, however it might be clearer
to say that "'ifstream' not found" since the message
says that 'ifstream' may be something other than a
type.
"error: ifstream not found"
"note: candidates are in #include "
/*
* m3.cpp
*/
# include
# include
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
g++3.4.4 messaging
m3.cpp:6: error: aggregate `std::ifstream x' has incomplete type and cannot be
defined
m3.cpp:6: error: storage size of `x' isn't known
Messaging not clear. The naive issue is the 'ifstream' not found.
'std::ifstream' not
found. 'std::ifstream x' is confusing.
If 'std::ifstream' not found, why is 'std::ifstream y();' legal?
"error: ifstream incomplete in 'istream'.
cleanup tests failing on MIPS64
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 changes. Does somebody know what's going on? I'll look at it otherwise. Adam
Question about top-level configure code and in-tree builds
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 building scenarios, but the issue can be seen by examining the current gmp/mpfr in-tree builds as well. So I'll stick to that in my explanation. Imagine the following scenario: 1. You're building gcc. 2. You have gmp installed in a location requiring --with-gmp=foo. 3. You do not have mpfr installed, so you unpack it in your source tree and expect it to be built during bootstrap using the gmp you specified in step 2. Now e.g. you're passing --with-gmp=/opt/cfarm/gmp-4.2.4 to configure. Inside Makefile.def the mpfr in-tree build code also adds --with-gmp-build=PATH_TO_IN_TREE_GMP to your configure (via extra_configure_flags) assuming that if you're building mpfr in-tree that you are also building gmp in-tree. But we are not. So when mpfr is built in-tree you get two different locations for gmp passed to it. Depending on how mpfr's configure argument processing code is written, it might be forgiving and pass two -I/-L flags during the build. Or as is the actual case with mpfr, one might override the other and you hope the one you want gets used. By chance it works today because of the flag processing order in mpfr's configure. However this seems extremely fragile and is a latent bug IMHO. 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 mechanism into my patch for adding mpc. Any assistance would be greatly appreciated. Thanks, --Kaveh
Re: question on 16 bit registers with 32 bit pointers
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 are on 32 bit and are stored in > two following registers (N and N+1). > > I did implement a GCC option to select between the two modes, and I'm using > this option to select the size of the pointers and Pmode: > > #define Pmode ((TARGET_16) ? HImode : SImode) #define POINTER_SIZE > ((TARGET_16) ? 16 : 32) > > 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 pointers, but you still need to write the patterns. > Is there something special I need to do to express the relationship between > the two registers N and N+1 composing a pointer, or does GCC automatically > allocate two subsequent HI registers when it needs a SI one ? GCC always uses consecutive hard regs when doing multi-reg data sizes. See HARD_REGNO_MODE_OK in the internals docs. cheers, DaveK
c99 stdint.h question
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 from c99-stdint-1.c. The header files seem OK and the test seems
like it should work but I get an error even when I don't use the header
files and make everthing explicitly unsigned.
$ 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: pointer targets in initialization differ in signedness
The 255 constant has the u suffix on it like it should and uint8_t
is defined as 'unsigned char' like it should be but I still get an error.
Why? Is there some type promotion going on under the covers?
Steve Ellcey
s...@cup.hp.com
Re: Possible messaging changes
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 by a default constructor. It's a forward declaration of a function y() taking no args and returning an ifstream object by value. cheers, DaveK
Re: Question about top-level configure code and in-tree builds
"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 mechanism into my > patch for adding mpc. 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...@. In Makefile.def change the host_modules entry for module=mpfr to replace --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp with $(EXTRA_MPFR_CONFIGURE_ARGS). Run autoconf and autogen. Easy as cake. Ian
Redirecting I/O
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 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 incompatible, as in:
bool condition;
ofstream x;
ofstream out = (condition)?cout: x; // won't work because of cout
int main(..){
out = cout;// won't work
}
In addition I would like to redirect an ofstream object to be the same as
out, as in;
void fn() { object = out; } // won't work because '=' is private.
Anyone know how to solve these two issues?
Re: c99 stdint.h question
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: pointer targets in initialization differ in signedness
>
> The 255 constant has the u suffix on it like it should and uint8_t
> is defined as 'unsigned char' like it should be but I still get an error.
> Why? Is there some type promotion going on under the covers?
Yes, unsigned types narrower than int are promoted to signed int in
arithmetic, and C99 (plus TCs - this was unclear in the original standard)
requires the macros for constants and limits to use the promoted types.
Thus UINT8_MAX should have type int, and UINT8_C should generate a
constant of type int. Headers doing otherwise should be fixed upstream
and with fixincludes.
--
Joseph S. Myers
jos...@codesourcery.com
Re: Redirecting I/O
(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 incompatible, as in:
>
> bool condition;
> ofstream x;
> ofstream out = (condition)?cout: x; // won't work because of cout
Try:
ostream& out = condition ? cout : x;
> In addition I would like to redirect an ofstream object to be the same as
> out, as in;
>
> void fn() { object = out; } // won't work because '=' is private.
Again, try declaring object as "ostream&".
-cary
Re: question on 16 bit registers with 32 bit pointers
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 pointers are on 16 bit (a full > > register), in the second one the pointers are on 32 bit and are stored in > > two following registers (N and N+1). > > > > I did implement a GCC option to select between the two modes, and I'm using > > this option to select the size of the pointers and Pmode: > > > > #define Pmode ((TARGET_16) ? HImode : SImode) #define > > POINTER_SIZE > > ((TARGET_16) ? 16 : 32) > > > > 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 pointers, but you still need to write the patterns. The thing is that this CPU does not have any real 32 bit registers, or instructions to do assignments/additions/etc to 32 bit registers. So the 32 bit operations (on pointers) need to be emulated using the 16 bit components, and I thought that GCC can do this automatically for me ... > > Is there something special I need to do to express the relationship between > > the two registers N and N+1 composing a pointer, or does GCC automatically > > allocate two subsequent HI registers when it needs a SI one ? > > GCC always uses consecutive hard regs when doing multi-reg data sizes. See > HARD_REGNO_MODE_OK in the internals docs. Great, thanks ! Stelian. -- Stelian Pop
Re: Possible messaging changes
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_ios td::char_traits >&)':
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ios_base.h:784: error:
> `std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
> m1.cpp:10: error: within this context
> m1.cpp: In member function `std::basic_filebuf
> >& std::basic_filebuf >::operator=(const
> std::basic_fil
> ebuf >&)':
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/streambuf:776: error:
> `std::basic_streambuf<_CharT, _Traits>& std::basic_streambuf<_CharT,
> _Traits>::operator=(con
> st std::basic_streambuf<_CharT, _Traits>&) [with _CharT = char, _Traits =
> std::char_traits]' is private
> m1.cpp:10: error: within this context
>
> Almost indecipherable. The error is that operator=() is private.
> "error: assignment illegal, operator '=' private in ifstream"
gcc 3.4.4 is a bit old. I tried current mainline, and I got this:
In file included from
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/ios:39,
from
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/istream:40,
from
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/fstream:40,
from foo.cc:1:
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/ios_base.h:
In member function ‘std::basic_ios&
std::basic_ios::operator=(const std::basic_ios&)’:
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/bits/ios_base.h:793:
error: ‘std::ios_base& std::ios_base::operator=(const std::ios_base&)’ is
private
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:47:
error: within this context
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:
In member function ‘std::basic_istream&
std::basic_istream::operator=(const std::basic_istream&)’:
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:53:
note: synthesized method ‘std::basic_ios&
std::basic_ios::operator=(const std::basic_ios&)’ first required
here
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:
In member function ‘std::basic_ifstream&
std::basic_ifstream::operator=(const std::basic_ifstream&)’:
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:81:
note: synthesized method ‘std::basic_istream&
std::basic_istream::operator=(const std::basic_istream&)’ first
required here
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/streambuf:
In member function ‘std::basic_filebuf&
std::basic_filebuf::operator=(const std::basic_filebuf&)’:
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/streambuf:778:
error: ‘std::basic_streambuf<_CharT, _Traits>::__streambuf_type&
std::basic_streambuf<_CharT, _Traits>::operator=(const
std::basic_streambuf<_CharT, _Traits>::__streambuf_type&) [with _CharT = char,
_Traits = std::char_traits, std::basic_streambuf<_CharT,
_Traits>::__streambuf_type = std::basic_streambuf]’ is private
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:78:
error: within this context
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:
In member function ‘std::basic_ifstream&
std::basic_ifstream::operator=(const std::basic_ifstream&)’:
/home/iant/gcc/install/lib/gcc/i686-pc-linux-gnu/4.5.0/../../../../include/c++/4.5.0/iosfwd:81:
note: synthesized method ‘std::basic_filebuf&
std::basic_filebuf::operator=(const std::basic_filebuf&)’ first
required here
foo.cc: In function ‘int main(int, char**)’:
foo.cc:10: note: synthesized method ‘std::basic_ifstream&
std::basic_ifstream::operator=(const std::basic_ifstream&)’ first
required here
So the compiler is trying to show you how it got to the point where it
needed the private function. I have to agree that it does rather
obscure the issue, though. At least "std::char_traits" is gone.
Filed as http://gcc.gnu.org/PR39728 .
> using namespace std;
>
> ifstream x;
> ifstream y();
>
> int main(int argc, char** argv) {
> return 0;
> }
>
> g++.3.4.4 output
> m2.cpp:4: error: `ifstream' does not name a type
> m2.cpp:5: error: `ifstream' does not name a type
>
> Succint and clear message, however it might be clearer
> to say that "'ifstream' not found" since the message
> says that 'ifstream' may be something other than a
> type.
>
> "error: ifstream not found"
> "note: candidates are in #include "
Mainline gcc has the same message
Re: GCC RES: Restrictive Exception Specification: 0.1 - Alpha. Feedback Request.
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: - It does not alter the output in any way. - It has no impact on compilation and compilation speed when not explicitly invoked. - The code is structured to make any future maintenance painless. I'm reluctant to add an extension which requires people to modify all their code in a non-conformant way if they want to use it. I'm sympathetic to your suggested changes to C++, but I'd like to see some indication that they might make it into a future standard before accepting a patch along these lines. My impression is that the C++ committee generally feel that exception specifications are a failed feature, and nobody is particularly interested in fixing them. > It should also be very easy to add a switch to instruct G++ to ignore all exception specifications when generating code, if necessary. There is one already: -fno-enforce-eh-specs Jason
Re: GCC RES: Restrictive Exception Specification: 0.1 - Alpha. Feedback Request.
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/2009/n2855.html -Chris
Re: GCC RES: Restrictive Exception Specification: 0.1 - Alpha. Feedback Request.
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/docs/papers/2009/n2855.html I've been aware of that discussion going on. That paper proposes to deprecate exception specifications in favor of a new decl-specifier that is roughly equivalent to an empty throw-spec. It seems unfortunate to me to introduce entirely new syntax for something so semantically similar, but I haven't really participated in the discussion. However, since the subject is being brought forward because of the issues with rvalue references, this does seem like an appropriate time to suggest changes to the semantics of exception specifications to make them more suitable to dealing with this issue. Jason
operator=() issue
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 : 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 >&)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ios_base.h:784: error:
`std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
x.cpp:9: error: within this context
Program 2 succeeds
# include
using namespace std;
class thing : private ios_base {
ostream* yo;
public:
thing(ostream& y) { yo = &y; }
thing(ostream y) { yo = &y; }
};
Program 4 fails
# include
using namespace std;
class thing : private ios_base {
ios_base& xo;
public:
thing(ios_base& y) { xo = y; }
};
gcc.3.4.4 messaging
x.cpp: In constructor `thing::thing(std::ios_base&)':
x.cpp:9: error: uninitialized reference member `thing::xo'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ios_base.h:784: error:
`std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
x.cpp:9: error: within this context
Re: operator=() issue
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 private inheritance does not grant access to private methods in the parent class. It merely prohibits access to the parent class by users of the class. Ian
Re: operator=() issue
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 : 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 >&)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ios_base.h:784: error:
`std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
x.cpp:9: error: within this context
std::ios_base was never meant to be copy-able/assign-able, this has
nothing to do with public/private *inheritance*, since it is the members
of the base that are private, and thus inaccessible to any derived
classes.
In your thing::thing ctor:
"xo(y)" initializes the member *reference* (essentially taking the address
of y), whereas "xo = y;" is assigning the *object* referenced by 'ox',
which is not the same. This is why you hit the inaccessible assignment
error.
HTH,
Fang
David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/
Re: operator=() issue
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 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 that are not members of either the base or derived class." If you can, could you please provide a citation which contradicts Schildt? The examples have a derived class with a private access specifier to a base class which should allow access to base class private members, and I assume, functions - there is no privacy when you are so derived. Given the above quote the behavior seen by gcc is unexpected. Given your statement it appears that an access specifier of 'private' has no effect. art --- On Fri, 4/10/09, Ian Lance Taylor wrote: > From: Ian Lance Taylor > Subject: Re: operator=() issue > To: "Arthur Schwarz" > Cc: gcc@gcc.gnu.org > Date: Friday, April 10, 2009, 4:48 PM > 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 private > inheritance does not > grant access to private methods in the parent class. > It merely > prohibits access to the parent class by users of the > class. > > Ian >
Re: question on 16 bit registers with 32 bit pointers
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 pointers, but you still need to write the patterns. > > The thing is that this CPU does not have any real 32 bit registers, or > instructions to do assignments/additions/etc to 32 bit registers. So the 32 > bit > operations (on pointers) need to be emulated using the 16 bit components, and > I > thought that GCC can do this automatically for me ... Ah. In theory GCC should move everything by pieces. In practice, you have to define mov patterns for SI and DI because rtl-level CSE isn't as smart as it should be. You can use expanders for these. cheers, DaveK
Re: operator=() issue
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 that are > not members of either the base or derived class." This says that with private inheritance, _public_ and _protected_ mmbers of the base become private members of the derived class. It doesn't say anything about _private_ members of the base. They remain private to the base, and inaccessible in the derived class. Ian
Re: operator=() issue
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 the C++ standard. If your description is correct, Schildt got it wrong, but I'd want to see the exact example before accusing Schildt of making an error. Private inheritance will never allow a use that public inheritance will not allow; a derived class can never access the private members of the class it derives from.
Re: operator=() issue
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 >&)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ios_base.h:784: error:
`std::ios_base& std::ios_base::operator=(const std::ios_base&)' is private
x.cpp:9: error: within this context
std::ios_base was never meant to be copy-able/assign-able, this has nothing
to do with public/private *inheritance*, since it is the members of the base
that are private, and thus inaccessible to any derived classes.
In your thing::thing ctor:
"xo(y)" initializes the member *reference* (essentially taking the address of
y), whereas "xo = y;" is assigning the *object* referenced by 'ox', which is
not the same. This is why you hit the inaccessible assignment error.
The real problem is that you are assigning an ostream to an ostream,
which is not allowed *in any context* because ostream ultimately derives
from ios_base, which privatizes assignment. You are seeing this message
about ios_base (misleading you to think it has to do with your thing class
inheriting from ios_base) because the default assignment of class ostream
(not explicitly defined) is invoking the default assignments of its base
classes, including ios_base. This is more an issue of mis-using the
standard ostream class.
Fang
David Fang
http://www.csl.cornell.edu/~fang/
http://www.achronix.com/
Re: operator=() issue
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: Friday, April 10, 2009, 5:45 PM
> 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::char_traits >&
> std::basic_ios
> >::operator=(const std::basic_ios std::char_traits >&)':
> >>
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/ios_base.h:784:
> error: `std::ios_base& std::ios_base::operator=(const
> std::ios_base&)' is private
> >> x.cpp:9: error: within this context
> >
> > std::ios_base was never meant to be
> copy-able/assign-able, this has nothing to do with
> public/private *inheritance*, since it is the members of the
> base that are private, and thus inaccessible to any derived
> classes.
> >
> > In your thing::thing ctor:
> >
> > "xo(y)" initializes the member *reference*
> (essentially taking the address of y), whereas "xo = y;" is
> assigning the *object* referenced by 'ox', which is not the
> same. This is why you hit the inaccessible assignment
> error.
>
> The real problem is that you are assigning an ostream to an
> ostream, which is not allowed *in any context* because
> ostream ultimately derives from ios_base, which privatizes
> assignment. You are seeing this message about ios_base
> (misleading you to think it has to do with your thing class
> inheriting from ios_base) because the default assignment of
> class ostream (not explicitly defined) is invoking the
> default assignments of its base classes, including
> ios_base. This is more an issue of mis-using the
> standard ostream class.
>
> Fang
>
> David Fang
> http://www.csl.cornell.edu/~fang/
> http://www.achronix.com/
>
>
Re: Question about top-level configure code and in-tree builds
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...@. In > Makefile.def change the host_modules entry for module=mpfr to replace > --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp with > $(EXTRA_MPFR_CONFIGURE_ARGS). Run autoconf and autogen. > > Easy as cake. Ah, but cake is only easy when someone else bakes it. :-) Anyway, thanks for the laser-like specific answer, that was extremely helpful. I'm testing a patch, but I have two notes to run by you. 1. You mentioned adding EXTRA_MPFR_CONFIGURE_ARGS to Makefile.in. (I think you mean Makefile.tpl, cause Makefile.in is generated?) Anyway, I managed to avoid adding the intermediate make variable and just put @extra_mpfr_configure_args@ in the module=mpfr entry and it worked. Is there some stylistic or syntactic reason to use the intermediate variable? It doesn't seem to be done 100% consistently. 2. In my previous message I said that mpfr worked by chance and the bug was latent but the situation fragile. That is true for mpfr-2.3.2. However the mpfr-2.4.1 tarball hard-errors on a double --with-gmp*, apparently by design. E.g. this is from building an unpatched gcc with in-tree mpfr-2.4.1 plus the configure flag --with-gmp=/opt/... > configure: error: Do not use --with-gmp-build and other --with-gmp options > simultaneously. > See `config.log' for more details. > make[1]: *** [configure-mpfr] Error 1 So IMHO when I finish testing we should install the patch on all active branches to forestall any issues when people upgrade to the later mpfr releases. Regards, --Kaveh
Re: Question about top-level configure code and in-tree builds
"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_CONFIGURE_ARGS = @extra_mpfr_configure_a...@. In >> Makefile.def change the host_modules entry for module=mpfr to replace >> --with-gmp-build=$$r/$(HOST_SUBDIR)/gmp with >> $(EXTRA_MPFR_CONFIGURE_ARGS). Run autoconf and autogen. >> >> Easy as cake. > > Ah, but cake is only easy when someone else bakes it. :-) > > > Anyway, thanks for the laser-like specific answer, that was extremely > helpful. I'm testing a patch, but I have two notes to run by you. > > 1. You mentioned adding EXTRA_MPFR_CONFIGURE_ARGS to Makefile.in. (I > think you mean Makefile.tpl, cause Makefile.in is generated?) Yes, Makefile.tpl, sorry. I was thinking that but evidently my fingers typed Makefile.in. > Anyway, I > managed to avoid adding the intermediate make variable and just put > @extra_mpfr_configure_args@ in the module=mpfr entry and it worked. Is > there some stylistic or syntactic reason to use the intermediate variable? > It doesn't seem to be done 100% consistently. You're right, it's not consistent. My personal preference is to use a make variable because it gives a clear place for people to override from the make command line. But for an obscure item like this it's not a big deal. > 2. In my previous message I said that mpfr worked by chance and the bug > was latent but the situation fragile. That is true for mpfr-2.3.2. > However the mpfr-2.4.1 tarball hard-errors on a double --with-gmp*, > apparently by design. E.g. this is from building an unpatched gcc with > in-tree mpfr-2.4.1 plus the configure flag --with-gmp=/opt/... > > > configure: error: Do not use --with-gmp-build and other --with-gmp options > simultaneously. > > See `config.log' for more details. > > make[1]: *** [configure-mpfr] Error 1 > > So IMHO when I finish testing we should install the patch on all active > branches to forestall any issues when people upgrade to the later mpfr > releases. Sounds good to me. Ian
