Re: Fixing the pre-pass scheduler on x86 (Bug 38403)
Another algorithm for live-range shrinkage I am trying to restore expression DAG and reorder insns in Sethi-Ulman enumeration style. This would be done best in TER (actually, in place of TER but using the same data structures it computes). Paolo
Re: Fwd: Objective-C and C99 strict aliasing
On Fri, Apr 10, 2009 at 3:41 AM, Ian Lance Taylor i...@google.com wrote: John Engelhart john.engelh...@gmail.com 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 ebotca...@adacore.com 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) CONVERT_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) PLUS_EXPR: Propagate the type of the first operand. (follow_ssa_edge_in_rhs) GIMPLE_BINARY_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 i...@google.com wrote: John Engelhart john.engelh...@gmail.com 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 melanie.blo...@intel.com 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 stel...@popies.net
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 fstream
# include istream
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_ioschar, std::char_traitschar
std::basic_ioschar, std::char_traitschar ::operator=(const
std::basic_ioschar, s
td::char_traitschar )':
/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_filebufchar, std::char_traitschar
std::basic_filebufchar, std::char_traitschar ::operator=(const
std::basic_fil
ebufchar, std::char_traitschar )':
/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_traitschar]' 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 fstream
/*
* m3.cpp
*/
# include istream
# include istream
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 istream # include istream 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 gh...@caip.rutgers.edu 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 stel...@popies.net
Re: Possible messaging changes
Arthur Schwarz aschwarz1...@verizon.net writes:
# include fstream
# include istream
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_ioschar, std::char_traitschar
std::basic_ioschar, std::char_traitschar ::operator=(const
std::basic_ioschar, s
td::char_traitschar )':
/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_filebufchar, std::char_traitschar
std::basic_filebufchar, std::char_traitschar ::operator=(const
std::basic_fil
ebufchar, std::char_traitschar )':
/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_traitschar]' 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_ioschar
std::basic_ioschar::operator=(const std::basic_ioschar)’:
/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_istreamchar
std::basic_istreamchar::operator=(const std::basic_istreamchar)’:
/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_ioschar
std::basic_ioschar::operator=(const std::basic_ioschar)’ 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_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar)’:
/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_istreamchar
std::basic_istreamchar::operator=(const std::basic_istreamchar)’ 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_filebufchar
std::basic_filebufchar::operator=(const std::basic_filebufchar)’:
/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_traitschar, std::basic_streambuf_CharT,
_Traits::__streambuf_type = std::basic_streambufchar]’ 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_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar)’:
/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_filebufchar
std::basic_filebufchar::operator=(const std::basic_filebufchar)’ first
required here
foo.cc: In function ‘int main(int, char**)’:
foo.cc:10: note: synthesized method ‘std::basic_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar)’ 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_traitschar 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
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 ostream
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_ioschar, std::char_traitschar
std::basic_ioschar, std::char_traitschar ::operator=(const
std::basic_ioschar, std::char_traitschar )':
/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 ostream
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 ostream
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 aschwarz1...@verizon.net 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 ostream
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_ioschar, std::char_traitschar std::basic_ioschar,
std::char_traitschar ::operator=(const std::basic_ioschar, std::char_traitschar )':
/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 i...@google.com wrote: From: Ian Lance Taylor i...@google.com Subject: Re: operator=() issue To: Arthur Schwarz aschwarz1...@verizon.net Cc: gcc@gcc.gnu.org Date: Friday, April 10, 2009, 4:48 PM Arthur Schwarz aschwarz1...@verizon.net 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 aschwarz1...@verizon.net 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 ostream
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_ioschar, std::char_traitschar
std::basic_ioschar, std::char_traitschar ::operator=(const
std::basic_ioschar, std::char_traitschar )':
/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 f...@csl.cornell.edu wrote:
From: David Fang f...@csl.cornell.edu
Subject: Re: operator=() issue
To: Arthur Schwarz aschwarz1...@verizon.net
Cc: gcc@gcc.gnu.org
Date: Friday, April 10, 2009, 5:45 PM
One more thing to add ...
Program 1 fails
# include ostream
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_ioschar,
std::char_traitschar
std::basic_ioschar, std::char_traitschar
::operator=(const std::basic_ioschar,
std::char_traitschar )':
/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 gh...@caip.rutgers.edu 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
[Bug testsuite/39710] gcc.misc-tests/help.exp doesn't work when configured with --enable-checking=assert
-- rwild at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rwild at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-10 06:03:08 date|| Summary|gcc.misc-tests/help.exp |gcc.misc-tests/help.exp |doesn't work when configured|doesn't work when configured |with --enable- |with --enable- |checking=assert |checking=assert http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39710
[Bug c++/39711] New: fail to use template template parameter with default values
$g++ -v -save-temps test1.cpp Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-7' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Debian 4.3.3-7) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.3/cc1plus -E -quiet -v -D_GNU_SOURCE test1.cpp -mtune=generic -fpch-preprocess -o test1.ii ignoring nonexistent directory /usr/lib/gcc/i486-linux-gnu/4.3.3/../../../../i486-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/include/c++/4.3 /usr/include/c++/4.3/i486-linux-gnu /usr/include/c++/4.3/backward /usr/local/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include /usr/lib/gcc/i486-linux-gnu/4.3.3/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/i486-linux-gnu/4.3.3/cc1plus -fpreprocessed test1.ii -quiet -dumpbase test1.cpp -mtune=generic -auxbase test1 -version -o test1.s GNU C++ (Debian 4.3.3-7) version 4.3.3 (i486-linux-gnu) compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.4.1-p2. warning: GMP header version 4.2.4 differs from library version 4.2.2. warning: MPFR header version 2.4.1-p2 differs from library version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c88e63435cdcbb6cdbdd73c6b0b8618a test1.cpp: In function âint main()â: test1.cpp:14: error: type/value mismatch at argument 3 in template parameter list for âtemplateclass Key, class Data, templateclass, class class Map class Aâ test1.cpp:14: error: expected a template of type âtemplateclass, class class Mapâ, got âtemplateclass _Key, class _Tp, class _Compare, class _Alloc class std::mapâ test1.cpp:14: error: invalid type in declaration before â;â token ps: g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) have no problems here. -- Summary: fail to use template template parameter with default values Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: urykhy at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug c++/39711] fail to use template template parameter with default values
--- Comment #1 from urykhy at gmail dot com 2009-04-10 06:11 --- Created an attachment (id=17610) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17610action=view) source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug c++/39711] fail to use template template parameter with default values
--- Comment #2 from urykhy at gmail dot com 2009-04-10 06:12 --- Created an attachment (id=17611) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17611action=view) preprocessed code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug testsuite/39710] gcc.misc-tests/help.exp doesn't work when configured with --enable-checking=assert
--- Comment #1 from rwild at gcc dot gnu dot org 2009-04-10 06:12 --- patch at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00769.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39710
[Bug c++/39711] fail to use template template parameter with default values
--- Comment #3 from urykhy at gmail dot com 2009-04-10 06:15 --- please, let me know if you need more information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #2 from bonzini at gnu dot org 2009-04-10 06:42 --- The Fortran problem is a real bug in the front-end that was masked by folding. The problem is that we're folding less than without my patch. I'll prepare a patch to both fix the Fortran problem and reestablish the folding. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-10 06:42:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug c/39712] New: type mismatch in address expression
Hi, i have problem when compiling mplayer-svn. TIA == bash-4.0$ cc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-bootstrap --disable-multilib Thread model: posix gcc version 4.5.0 20090409 (experimental) (GCC) bash-4.0$ pwd /home/user/d/mplayer/libavcodec bash-4.0$ cc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I.. -I.. -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=native -mtune=native -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -Ilibdvdread4 -I/0/include/freetype2 -I/0/include -c -o mpegaudiodec.o mpegaudiodec.c mpegaudiodec.c: In function : mpegaudiodec.c:1647: error: type mismatch in address expression int32_t[16] * int32_t[2][16] * is_tab = is_table; mpegaudiodec.c:1647: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: type mismatch in address expression Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: happyarch at gmail dot com GCC build triplet: x86_64 GCC host triplet: x86_64 GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712
[Bug c/39712] type mismatch in address expression
--- Comment #1 from happyarch at gmail dot com 2009-04-10 06:50 --- Created an attachment (id=17612) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17612action=view) preprocessed output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #3 from bonzini at gnu dot org 2009-04-10 06:55 --- The pr36901-* are correct to fail IMO -- they now give an initializer is not constant error which they weren't giving before -- because you cannot know in principle that sc 0 at compile-time, you have to wait for linking. -- bonzini at gnu dot org changed: What|Removed |Added Last reconfirmed|2009-04-10 06:42:47 |2009-04-10 06:55:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #11 from jb at gcc dot gnu dot org 2009-04-10 07:23 --- Subject: Bug 39665 Author: jb Date: Fri Apr 10 07:23:25 2009 New Revision: 145875 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145875 Log: 2009-04-10 Janne Blomqvist j...@gcc.gnu.org PR libfortran/39665 libfortran/39702 libfortran/39709 * io/io.h (st_parameter_dt): Revert aligned attribute from u.p.value. * io/list_read.c (read_complex): Read directly into user pointer. (read_real): Likewise. (list_formatted_read_scalar): Update read_complex and read_real calls. (nml_read_obj): Read directly into user pointer. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/io.h trunk/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug c/39712] [4.5 Regression] type mismatch in address expression
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-10 08:18 --- Likely due to my patch. I'll have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||ice-on-valid-code, wrong- ||code Last reconfirmed|-00-00 00:00:00 |2009-04-10 08:18:15 date|| Summary|type mismatch in address|[4.5 Regression] type |expression |mismatch in address ||expression Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712
[Bug c/39712] [4.5 Regression] type mismatch in address expression
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-10 08:56 ---
Reduced testcase:
int is_table[2][16];
int is_table_lsf[2][2][16];
void compute_stereo()
{
int (*is_tab)[16];
is_tab = is_table;
}
interestingly removing the unrelated is_table_lsf decl makes the error go away.
Which is maybe a type sharing issue and due to the fact that we eventually
end up asking the FE about array type compatibility.
I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712
[Bug c++/39711] fail to use template template parameter with default values
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-10 09:40 --- This is illegal in C++03, because std::map has 4 template parameters, no matter the defaults. Changing class A like the below works. In c++0x, thanks to typedef templates neater solutions will be possible. template typename Key, typename Data, template typename Key, typename Data, typename = std::lessKey, typename = std::allocatorstd::pairconst Key, Data class Map ... -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
[Bug tree-optimization/39713] New: [4.4/4.5 Regression] ICE in get_expr_value_id
Since r141534 (PR37542), the following testcase segfaults during fre at -O1 and
higher:
template typename To, typename From
static inline To
bitwise_cast (From from)
{
union
{
From f;
To t;
} u;
u.f = from;
return u.t;
}
extern void foo (unsigned char *);
double
bar ()
{
unsigned char b[sizeof (unsigned long long)];
foo (b);
return bitwise_castdouble (*(unsigned long long *) b);
}
--
Summary: [4.4/4.5 Regression] ICE in get_expr_value_id
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
[Bug tree-optimization/39713] [4.4/4.5 Regression] ICE in get_expr_value_id
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
[Bug c++/39699] No error reporting when function and variable have the same name
--- Comment #3 from dodji at gcc dot gnu dot org 2009-04-10 11:46 ---
Subject: Re: No error reporting when function and variable
have the same name
alpha dot super-one at laposte dot net a écrit :
--- Comment #2 from alpha dot super-one at laposte dot net 2009-04-10
04:47 ---
So I compiled this program:
1 class toto
2 {
3enum e {a,b};
4e test_example();
5e test_example;
6 };
7
8 toto t;
with the -Wall option of g++ 4.3.2, I got:
test.cc:5: error: declaration of 'toto::e toto::test_example'
test.cc:4: error: conflicts with previous declaration 'toto::e
toto::test_example()'
So that does what you want I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699
[Bug target/39714] New: cond-optab fallout meta-bug
This bug groups testcases that worsen or (in one case) ICE on cond-optab branch. -- Summary: cond-optab fallout meta-bug Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39714
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
--- Comment #3 from ayers at gcc dot gnu dot org 2009-04-10 12:43 --- Created an attachment (id=17613) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17613action=view) rewrite of dispatch table installation I agree with the approach you describe, in that we need a look-a-side buffer for the dispatch table to send messages during +initialize and install the dtable after +initialize returns. I was not comfortable with the patch because: /* Assumes that __objc_runtime_mutex is locked down. * If receiver is not null, it is the object whos supercalss must be * initialised if the superclass of the one we are installing the * dispatch table for is not already installed. */ __objc_begin_install_dispatch_table_for_class (Class class, Class receiver) I still have a hard time groking what was intended with the receiver. It all seems very intertwined and I think there is a more straight forward way to implement this. Also, with this patch get_imp fails on class methods. (get_imp also has the nasty effect of installing the dispatch table without calling +initialize and the same goes for __objc_responds_to). I'm not to fond of introducing InitializingList as special type. I think should be fine with using the existing hash map tables for this. I don't think we really need to introduce a new type. Do you really think that method dispatch for partially installed dispatch tables is performance critical? Well... after all this complaining, let's get to something more constructive :-). I've attached a patch (including some test cases which still need to be augmented) that I'd like to propose for a reimplementation originally based on your code. I hope I've added enough comments and asserts to insure the assumptions and prerequisites are met. For the final submission I'll remove some of the asserts. It combines __objc_install_dispatch_table_for_class and __objc_init_install_dtable into: /* This function is called by: objc_msg_lookup, get_imp and __objc_responds_to (and the dispatch table installation functions themselves) to install a dispatch table for a class. If CLS is a class, it installs instance methods. If CLS is a meta class, it installs class methods. In either case +initialize is invoked for the corresponding class. The implementation must insure that the dispatch table is not installed until +initialize completes. Otherwise it opens a potential race since the installation of the dispatch table is used as gate in regular method dispatch and we need to guarantee that +initialize is the first method invoked an that no other thread my dispatch messages to the class before +initialize completes. */ static void __objc_install_dtable_for_class (Class cls) Which implements your suggestion with the following helper functions: static void __objc_prepare_dtable_for_class (Class cls); - builds the dispatch table and stores it in a look-a-side buffer (I used the hash tables instead of a custom type). static struct sarray *__objc_prepared_dtable_for_class (Class cls); - access the prepared table: this is used to identify whether the dispatch table is currently being installed (akin to the __objc_is_initializing_dispatch_table of the proposed patch) and is also used for subclasses that may be +initialized during the +initialize of the super class (i.e. class clusters when NSString's +initialize invokes GSString methods an need to copy NSString's dtable. static void __objc_install_prepared_dtable_for_class (Class cls); - static IMP __objc_get_prepared_imp (Class cls,SEL sel); Could you please have a look and let me know what you think? I'm still going to write some more test, checking the class cluster behavior mentioned above and I'll need some tests wrt to categories. So this is not final but it should address the main issue and the get_imp/__objc_responds_to issue. Cheers, David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug target/39715] New: [cond-optab] extra sign extensions on Thumb
/* -O1 -mthumb -march=armv5t */
struct foo
{
unsigned b31 : 1;
unsigned b30 : 1;
unsigned b29 : 1;
unsigned b28 : 1;
unsigned rest : 28;
};
foo(a)
struct foo a;
{
return a.b30;
}
should have only one lsl and lsr
--
Summary: [cond-optab] extra sign extensions on Thumb
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39715
[Bug target/39716] New: [cond-optab] worse MAX_EXPR expansion for Thumb
/* -O1 -mthumb -march=armv6t2 -ffinite-math-only */
float repl1 (float varx)
{
if (varx 0.0)
return 0.0;
return varx;
}
--
Summary: [cond-optab] worse MAX_EXPR expansion for Thumb
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39716
[Bug libobjc/38307] Calling of the +initialize method is not completely thread-safe
-- ayers at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-10 12:44:38 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38307
[Bug target/39717] New: [cond-optab] CSE does not put subregs into COMPAREs on many CC0 machines
/* cris and mn10300 -O2 */
foo (float *c)
{
union
{
float r;
unsigned int i;
}
e;
e.r = c[0];
if (e.i 0x3f7f) return (e.r = e.r / 2.0f, e.i);
return ((int) e.i 0) ? 0 : 255;
}
Probably this is a duplicate too for vax:
int a, b;
int baz (short x) { return x; }
int bar (int x) {
if (baz (a ^ x ^ a)) return b;
return 0;
}
int foo (void) {
return bar (a == 0 || 1 == 1 - a) ? 1 : bar (1 a);
}
--
Summary: [cond-optab] CSE does not put subregs into COMPAREs on
many CC0 machines
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39717
[Bug target/39718] New: [cond-optab] crash on crx in IRA
/* -O3 -funroll-loops */
int foo (long b, int c)
{
int d = 0, e;
while (b--)
{
e = 0;
if (!d) e = d = 1; else e = 0;
if (!(c 0x10) || !(c 0x4000) || !e) continue;
if (c 0x80) break;
}
}
--
Summary: [cond-optab] crash on crx in IRA
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39718
[Bug target/39719] New: [cond-optab] uses libcall instead of branch on m68hc11
Note that this is a win on most targets:
int
foo ()
{
extern long long Y;
return (0 Y++);
}
--
Summary: [cond-optab] uses libcall instead of branch on m68hc11
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39719
[Bug target/39720] New: [cond-optab] combine does not use LOAD_EXTEND_OP?
/* -O1 mn10300 */
int f (int a, int b, int c, _Bool d, _Bool e, _Bool f, char g)
{
if (g != 1 || d != 1 || e != 1 || f != 1) abort ();
return a + b + c;
}
int main (void)
{
if (f (1, 2, -3, 1, 1, 1, '\001'))
abort ();
exit (0);
}
--
Summary: [cond-optab] combine does not use LOAD_EXTEND_OP?
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39720
[Bug c++/20118] missing template causes weird errors
--- Comment #8 from manu at gcc dot gnu dot org 2009-04-10 12:48 --- Subject: Bug 20118 Author: manu Date: Fri Apr 10 12:47:58 2009 New Revision: 145892 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145892 Log: 2009-04-10 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/20118 cp/ * parser.c (cp_parser_check_template_parameters): Take a cp_declarator parameter. (cp_parser_elaborated_type_specifier): Update to cp_parser_check_template_parameters. (cp_parser_class_head): Likewise. (cp_parser_check_declarator_template_parameters): Likewise. (cp_parser_check_template_parameters): Handle first the non-error conditions. Give more accurate diagnostics if a declarator is given. testsuite/ * g++.dg/parse/pr20118.C: New. * g++.dg/template/spec16.C: Update. Added: trunk/gcc/testsuite/g++.dg/parse/pr20118.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/spec16.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20118
[Bug target/39721] New: [cond-optab] worse register allocation on mn10300
/* -O2 */
int dialog_calendar(int state)
{
int *obj = (state == 1 ? state : 0);
return (obj == state);
}
--
Summary: [cond-optab] worse register allocation on mn10300
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39721
[Bug target/39722] New: [cond-optab] worse code with bitfields on v850 and mn10300
struct S
{
unsigned int s;
};
struct T
{
struct S t[2];
unsigned int u : 1;
};
void
foo (int x, int y, int z)
{
int i;
struct T t;
t.u = t.u;
for (i = 0; i x; i++)
if (z != 1)
t.t[i].s = y || t.u;
}
--
Summary: [cond-optab] worse code with bitfields on v850 and
mn10300
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39722
[Bug c++/20118] missing template causes weird errors
--- Comment #9 from manu at gcc dot gnu dot org 2009-04-10 12:51 --- Fixed in GCC 4.5 -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20118
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-10 12:54 --- (In reply to comment #3) The pr36901-* are correct to fail IMO -- they now give an initializer is not constant error which they weren't giving before -- because you cannot know in principle that sc 0 at compile-time, you have to wait for linking. I think it is target specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug target/39723] New: [cond-optab] worse code with long long shifts on v850
long long xlrandom (long long x)
{
int bits = 64;
do
{
unsigned b = (random () 15) + 1;
x = b; /* shift up 1-16 steps */
bits -= b;
}
while (bits = 0);
return x;
}
--
Summary: [cond-optab] worse code with long long shifts on v850
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39723
[Bug target/39724] New: [cond-optab] reload_cse_simplify_operands complicates code on vax
reload_cse_simplify_operandss likes to change (compare REG (const_int 0)) to a
compare between registers on VAX, when it has a register at hand whose value is
zero. This pessimizes code and in some cases even introduces spurious compares
instead of using CC0.
/* -Os */
f(int count,double r,double *rho)
{
int i, j, miny, maxy, hy;
float help, d;
for (hy = miny; hy= maxy; hy++)
while(j =0)
if ( d = r) abort ();
}
--
Summary: [cond-optab] reload_cse_simplify_operands complicates
code on vax
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39724
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-04-10 14:04 --- Subject: Bug 25104 Author: dfranke Date: Fri Apr 10 14:04:16 2009 New Revision: 145907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145907 Log: gcc/fortran/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/25104 PR fortran/29962 * array.c (gfc_append_constructor): Added NULL-check. * check.c (gfc_check_spread): Check DIM. (gfc_check_unpack): Check that the ARRAY arguments provides enough values for MASK. * intrinsic.h (gfc_simplify_spread): New prototype. (gfc_simplify_unpack): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (gfc_simplify_spread): New. (gfc_simplify_unpack): New. * expr.c (check_transformational): Allow additional transformational intrinsics in initialization expression. gcc/testsuite/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/25104 PR fortran/29962 * gfortran.dg/spread_init_expr.f03: New. * gfortran.dg/unpack_init_expr.f03: New. * gfortran.dg/intrinsic_argument_conformance_2.f90: Adjusted error message. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/spread_init_expr.f03 branches/fortran-dev/gcc/testsuite/gfortran.dg/unpack_init_expr.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.dev branches/fortran-dev/gcc/fortran/array.c branches/fortran-dev/gcc/fortran/check.c branches/fortran-dev/gcc/fortran/expr.c branches/fortran-dev/gcc/fortran/intrinsic.c branches/fortran-dev/gcc/fortran/intrinsic.h branches/fortran-dev/gcc/fortran/simplify.c branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev branches/fortran-dev/gcc/testsuite/gfortran.dg/intrinsic_argument_conformance_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/38709] ICE on zero-sized array in initialization expression
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-10 14:12 --- Subject: Bug 38709 Author: dfranke Date: Fri Apr 10 14:12:01 2009 New Revision: 145909 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145909 Log: gcc/fortran/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/38709 * expr.c (find_array_section): Leave early on zero-sized arrays. gcc/testsuite/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/38709 * gfortran.dg/zero_sized_6.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/zero_sized_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38709
[Bug fortran/38709] ICE on zero-sized array in initialization expression
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-04-10 14:13 --- Fixed in trunk. Not a regression, no backport. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.5.0 Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38709
[Bug target/39725] New: [cond-optab] MIPS pessimizations on floating-point
MIPS floating-point comparisons are sometimes improved, sometimes pessimized. Here are the tests that are pessimized more: gcc.c-torture/execute/ieee/compare-fp-1.c gcc.c-torture/execute/ieee/compare-fp-4.c (-fno-trapping-math) gcc.c-torture/unsorted/DFcmp.c (not for all versions, but for example at -O1 -mfp32 -mgp32 they are affected). Just removing these three is enough to change from a depressing 513 files changed, 24582 insertions(+), 20790 deletions(-) to a decent 467 files changed, 15738 insertions(+), 15818 deletions(-) -- Summary: [cond-optab] MIPS pessimizations on floating-point Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bonzini at gnu dot org OtherBugsDependingO 39714 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39725
[Bug fortran/29962] Initialization expressions
--- Comment #16 from dfranke at gcc dot gnu dot org 2009-04-10 14:04 --- Subject: Bug 29962 Author: dfranke Date: Fri Apr 10 14:04:16 2009 New Revision: 145907 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145907 Log: gcc/fortran/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/25104 PR fortran/29962 * array.c (gfc_append_constructor): Added NULL-check. * check.c (gfc_check_spread): Check DIM. (gfc_check_unpack): Check that the ARRAY arguments provides enough values for MASK. * intrinsic.h (gfc_simplify_spread): New prototype. (gfc_simplify_unpack): Likewise. * intrinsic.c (add_functions): Added new simplifier callbacks. * simplify.c (gfc_simplify_spread): New. (gfc_simplify_unpack): New. * expr.c (check_transformational): Allow additional transformational intrinsics in initialization expression. gcc/testsuite/: 2009-04-10 Daniel Franke franke.dan...@gmail.com PR fortran/25104 PR fortran/29962 * gfortran.dg/spread_init_expr.f03: New. * gfortran.dg/unpack_init_expr.f03: New. * gfortran.dg/intrinsic_argument_conformance_2.f90: Adjusted error message. Added: branches/fortran-dev/gcc/testsuite/gfortran.dg/spread_init_expr.f03 branches/fortran-dev/gcc/testsuite/gfortran.dg/unpack_init_expr.f03 Modified: branches/fortran-dev/gcc/fortran/ChangeLog.dev branches/fortran-dev/gcc/fortran/array.c branches/fortran-dev/gcc/fortran/check.c branches/fortran-dev/gcc/fortran/expr.c branches/fortran-dev/gcc/fortran/intrinsic.c branches/fortran-dev/gcc/fortran/intrinsic.h branches/fortran-dev/gcc/fortran/simplify.c branches/fortran-dev/gcc/testsuite/ChangeLog.fortran-dev branches/fortran-dev/gcc/testsuite/gfortran.dg/intrinsic_argument_conformance_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #13 from pault at gcc dot gnu dot org 2009-04-10 14:27 --- (In reply to comment #12) Comment #11 should probably go to PR38802. Indeed - sorry. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug target/39726] New: [cond-optab] ColdFire pessimizations on QImode/HImode tests
unsigned char v;
int baz (unsigned char u, unsigned char w)
{
if ((u - w) 0x80)
v = 1;
}
Combine does not like as much as for m68k the RTL produced by the optimizers,
because of the lack of byte operations:
(insn 10 9 11 f.c:5 (set (reg:QI 35)
-(and:QI (subreg:QI (reg:SI 34) 3)
-(insn 11 10 12 f.c:5 (set (cc0)
-(compare (reg:QI 35)
(const_int 0 [0x0]))) -1 (nil))
vs.
(insn 10 9 11 f.c:5 (set (reg:QI 35)
+(subreg:QI (reg:SI 34) 3)) -1 (nil))
+
+(insn 11 10 12 f.c:5 (set (reg:SI 36)
+(and:SI (subreg:SI (reg:QI 35) 0)
(const_int -128 [0xff80]))) -1 (nil))
+(insn 12 11 13 f.c:5 (set (reg:QI 37)
+(subreg:QI (reg:SI 36) 3)) -1 (nil))
+
+(insn 13 12 14 f.c:5 (set (cc0)
+(compare (reg:QI 37)
(const_int 0 [0x0]))) -1 (nil))
The extra insn 12 is present because of this in dojump.c:
564 /* The RTL optimizers prefer comparisons against pseudos. */
565 if (GET_CODE (temp) == SUBREG)
566 {
567 /* Compare promoted variables in their promoted mode. */
568 if (SUBREG_PROMOTED_VAR_P (temp)
569REG_P (XEXP (temp, 0)))
570 temp = XEXP (temp, 0);
571 else
572 temp = copy_to_reg (temp);
573 }
--
Summary: [cond-optab] ColdFire pessimizations on QImode/HImode
tests
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39726
[Bug target/39727] New: [cond-optab] pessimization for FP compare with 0 on ColdFire
double testit(double _Complex* t)
{
return *t==0.0?0.0:-*t;
}
includes useless sequence like
clr.l -(%sp);clr.l -(%sp);fdmove.d (%sp)+,%fp1
fdmove.d (%a0),%fp0
fcmp.d %fp1,%fp0
where the first and last line are useless -- GCC could instead be using the
flags as set by a fdmove.d instruction.
--
Summary: [cond-optab] pessimization for FP compare with 0 on
ColdFire
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
OtherBugsDependingO 39714
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39727
[Bug target/39718] [cond-optab] crash on crx in IRA
--- Comment #1 from bonzini at gnu dot org 2009-04-10 15:25 ---
Another testcase, this one failing at -O2:
void foo (unsigned int n)
{
int i, j = -1;
for (i = 0; i 10 j 0; i++)
if ((1UL i) == n)
j = i;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39718
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #5 from hp at gcc dot gnu dot org 2009-04-10 15:28 --- For the record, seeing the same regressions for cris-elf, 145839:145857. Wrt. comment #3, if addresses were unsigned before (or this'd have failed), they should still be so, and this still be constant true, right? Regardless of target. (We know it's not NULL.) -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug c++/39699] No error reporting when function and variable have the same name
--- Comment #4 from alpha dot super-one at laposte dot net 2009-04-10 15:42 --- I have not that's in lot of version, my code tested is here: http://www.developpez.net/forums/m4191192-3/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #6 from bonzini at gnu dot org 2009-04-10 16:05 --- We know it's not NULL. I don't think the compiler can say so if not -fdelete-null-pointer-checks, and the flag is off at -O0 and -O1 (which is a separate bug and a separate patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #7 from bonzini at gnu dot org 2009-04-10 16:06 --- Subject: Bug 39701 Author: bonzini Date: Fri Apr 10 16:06:43 2009 New Revision: 145927 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145927 Log: 2009-04-10 Paolo Bonzini bonz...@gnu.org PR middle-end/39701 * fold-const.c (tree_single_nonzero_warnv_p): Pass non-static variables as non-NULL even with -fdelete-null-pointer-checks. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug libfortran/39702] [4.5 Regression] Unaligned access in Fortran testcases
--- Comment #7 from hjl dot tools at gmail dot com 2009-04-10 17:35 --- Fixed as of revision 145878. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39702
[Bug tree-optimization/39713] [4.4/4.5 Regression] ICE in get_expr_value_id
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-10 18:31 --- I will have a looksee. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-10 18:31:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
[Bug tree-optimization/39713] [4.4/4.5 Regression] ICE in get_expr_value_id
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-10 18:43 ---
I am testing the following
Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c(revision 145876)
+++ tree-ssa-sccvn.c(working copy)
@@ -257,9 +257,10 @@ vn_get_expr_for (tree name)
switch (TREE_CODE_CLASS (gimple_assign_rhs_code (def_stmt)))
{
case tcc_reference:
- if (gimple_assign_rhs_code (def_stmt) == VIEW_CONVERT_EXPR
- || gimple_assign_rhs_code (def_stmt) == REALPART_EXPR
- || gimple_assign_rhs_code (def_stmt) == IMAGPART_EXPR)
+ if ((gimple_assign_rhs_code (def_stmt) == VIEW_CONVERT_EXPR
+ || gimple_assign_rhs_code (def_stmt) == REALPART_EXPR
+ || gimple_assign_rhs_code (def_stmt) == IMAGPART_EXPR)
+ TREE_CODE (gimple_assign_rhs1 (def_stmt)) == SSA_NAME)
expr = fold_build1 (gimple_assign_rhs_code (def_stmt),
gimple_expr_type (def_stmt),
TREE_OPERAND (gimple_assign_rhs1 (def_stmt), 0));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
[Bug c++/28301] [4.3/4.4/4.5 regression] ICE with broken specialization
--- Comment #9 from hjl at gcc dot gnu dot org 2009-04-10 18:56 --- Subject: Bug 28301 Author: hjl Date: Fri Apr 10 18:56:07 2009 New Revision: 145936 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145936 Log: gcc/cp/ 2009-04-10 Jason Merrill ja...@redhat.com PR c++/28301 * parser.c (cp_parser_skip_to_end_of_block_or_statement): Return if we see a close brace without an open brace. gcc/testsuite/ 2009-04-10 H.J. Lu hongjiu...@intel.com PR c++/28301 * g++.dg/cpp0x/enum2.C: Updated. * g++.dg/debug/pr22514.C: Likewise. * g++.dg/parse/enum2.C: Likewise. * g++.dg/parse/enum3.C: Likewise. * g++.dg/template/crash79.C: Likewise. * g++.old-deja/g++.jason/cond.C: Likewise. * g++.dg/template/pr28301.C: New. Added: trunk/gcc/testsuite/g++.dg/template/pr28301.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/enum2.C trunk/gcc/testsuite/g++.dg/debug/pr22514.C trunk/gcc/testsuite/g++.dg/parse/enum2.C trunk/gcc/testsuite/g++.dg/parse/enum3.C trunk/gcc/testsuite/g++.dg/template/crash79.C trunk/gcc/testsuite/g++.old-deja/g++.jason/cond.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #13 from hjl at gcc dot gnu dot org 2009-04-10 18:58 --- Subject: Bug 39701 Author: hjl Date: Fri Apr 10 18:58:12 2009 New Revision: 145937 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145937 Log: 2009-04-10 H.J. Lu hongjiu...@intel.com PR middle-end/39701 * common.opt (-fdelete-null-pointer-checks): Initialize to 1. * opts.c (decode_options): Don't set flag_delete_null_pointer_checks here. * doc/invoke.texi: Update -fdelete-null-pointer-checks. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/doc/invoke.texi trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug c++/28301] [4.3/4.4/4.5 regression] ICE with broken specialization
--- Comment #10 from hjl at gcc dot gnu dot org 2009-04-10 19:01 --- Subject: Bug 28301 Author: hjl Date: Fri Apr 10 19:01:16 2009 New Revision: 145938 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145938 Log: gcc/cp/ 2009-04-10 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-10 Jason Merrill ja...@redhat.com PR c++/28301 * parser.c (cp_parser_skip_to_end_of_block_or_statement): Return if we see a close brace without an open brace. gcc/testsuite/ 2009-04-10 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-10 H.J. Lu hongjiu...@intel.com PR c++/28301 * g++.dg/cpp0x/enum2.C: Updated. * g++.dg/debug/pr22514.C: Likewise. * g++.dg/parse/enum2.C: Likewise. * g++.dg/parse/enum3.C: Likewise. * g++.dg/template/crash79.C: Likewise. * g++.old-deja/g++.jason/cond.C: Likewise. * g++.dg/template/pr28301.C: New. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/pr28301.C - copied unchanged from r145937, trunk/gcc/testsuite/g++.dg/template/pr28301.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/parser.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/cpp0x/enum2.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/debug/pr22514.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/enum2.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/parse/enum3.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash79.C branches/gcc-4_4-branch/gcc/testsuite/g++.old-deja/g++.jason/cond.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug fortran/38863] WHERE with multiple elemental defined assignments gives wrong answer
--- Comment #14 from pault at gcc dot gnu dot org 2009-04-10 19:06 --- (In reply to comment #9) The code in comment #1 still does not give the right result. I get (intel-darwin): No, it's not right. We have seen this before with module assignments involving derived types. It should be noted that this is an entirely different bug to the original one. In the case of the first, the dependency was missed. In this second, it is detected OK but the components of the lhs that are not assigned to by the module procedure are left indeterminate. Daniel, I expect this looks familiar Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added CC||d at domob dot eu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
[Bug c++/28301] [4.3/4.4/4.5 regression] ICE with broken specialization
--- Comment #11 from hjl at gcc dot gnu dot org 2009-04-10 19:36 --- Subject: Bug 28301 Author: hjl Date: Fri Apr 10 19:36:19 2009 New Revision: 145939 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145939 Log: gcc/cp/ 2009-04-10 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-10 Jason Merrill ja...@redhat.com PR c++/28301 * parser.c (cp_parser_skip_to_end_of_block_or_statement): Return if we see a close brace without an open brace. gcc/testsuite/ 2009-04-10 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-10 H.J. Lu hongjiu...@intel.com PR c++/28301 * g++.dg/debug/pr22514.C: Updated. * g++.dg/parse/enum2.C: Likewise. * g++.dg/parse/enum3.C: Likewise. * g++.dg/template/pr28301.C: New. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/pr28301.C - copied unchanged from r145938, trunk/gcc/testsuite/g++.dg/template/pr28301.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/parser.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/g++.dg/debug/pr22514.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/enum2.C branches/gcc-4_3-branch/gcc/testsuite/g++.dg/parse/enum3.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug c++/28301] [4.3/4.4/4.5 regression] ICE with broken specialization
--- Comment #12 from hjl dot tools at gmail dot com 2009-04-10 19:37 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28301
[Bug target/39727] [cond-optab] pessimization for FP compare with 0 on ColdFire
--- Comment #1 from bonzini at gnu dot org 2009-04-10 20:06 --- This was actually fixed already with local patches, at least above -O1. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|[cond-optab] pessimization |[cond-optab] pessimization |for FP compare with 0 on|for FP compare with 0 on |ColdFire|ColdFire http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39727
[Bug c++/39728] New: C++ diagnostic for private operator= is voluminous and unhelpful
For this test case:
# include fstream
# include istream
using namespace std;
ifstream x;
ifstream y = x;
int main(int argc, char** argv) {
y = x;
return 0;
}
current mainline g++ produces:
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_ioschar std::basic_ioschar::operator=(const
std::basic_ioschar):
/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_istreamchar
std::basic_istreamchar::operator=(const std::basic_istreamchar):
/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_ioschar
std::basic_ioschar::operator=(const std::basic_ioschar) 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_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar):
/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_istreamchar
std::basic_istreamchar::operator=(const std::basic_istreamchar) 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_filebufchar
std::basic_filebufchar::operator=(const std::basic_filebufchar):
/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_traitschar, std::basic_streambuf_CharT,
_Traits::__streambuf_type = std::basic_streambufchar] 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_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar):
/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_filebufchar
std::basic_filebufchar::operator=(const std::basic_filebufchar) first
required here
foo.cc: In function int main(int, char**):
foo.cc:10: note: synthesized method std::basic_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar) first
required here
Walking back from the point of error to the point of use can be helpful in some
scenarios. However, for an example like this one it is unhelpful and serves to
disguise the real problem.
I think we can use the walkback more intelligently and say something like:
foo.cc:10: error: cannot synthesize method std::basic_ifstreamchar
std::basic_ifstreamchar::operator=(const std::basic_ifstreamchar)
foo.cc:10: note: because std::ios_base std::ios_base::operator=(const
std::ios_base) is private
foo.cc:10: note: for details use -fvery-long-error-messages
--
Summary: C++ diagnostic for private operator= is voluminous and
unhelpful
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39728
[Bug c++/39729] New: C++ does not name a type error message can be misleading
For this C++ example:
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
current mainline g++ says this:
foo.cc:3: error: ifstream does not name a type
foo.cc:4: error: ifstream does not name a type
ifstream not only does not name a type, it is not defined at all in any way.
Let's say that instead of leading the user into trying to figure out what is
wrong with ifstream.
foo.cc:3: error: ifstream not defined
--
Summary: C++ does not name a type error message can be
misleading
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39729
[Bug c++/39730] New: C++ incomplete type error can be misleading
For this example:
# include istream
# include istream
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
current mainline g++ says:
foo.cc:6: error: aggregate std::ifstream x has incomplete type and cannot be
defined
This is accurate but confusing for the uninitiated. How about something like
foo.cc:6: error: std::ifstream was declared but not defined
--
Summary: C++ incomplete type error can be misleading
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39730
[Bug fortran/34040] relation between kinds and C types (for math builtins) shouldn't be hardcoded
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 20:44 --- Is this still valid? Is there a relation to PR21203? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
[Bug fortran/36553] Missing interface not detected in call to same file function
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-04-10 20:50 --- Dominique, any improvements here with -fwhole-file? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
[Bug fortran/37605] Remarks on user manual for Gfortran
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:03 --- Closing as this seems to be completed. Please reopen if there's an issue left. Thanks for the reports! -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37605
[Bug fortran/25829] [F2003] Asynchronous IO support
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-10 21:23 --- Jerry, is this complete? If not, could you please summarize what's left? Thanks. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
-- dfranke at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-12 21:18:24 |2009-04-10 21:26:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/24886] different character length in actual and formal argument not detected
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:35 --- With the commit in comment #9 we get: $ gfortran-svn -fwhole-file -Wall pr24886.f [...] pr24886.f:8.20: call foo(x) 1 Warning: Character length of actual argument shorter than of dummy argument 'y' (10/20) at (1) Paul, can we close this one? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
