[Bug ada/29025] [4.0/4.1/4.2 regression] procedure doesn't modify In Out parameter

--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-09-12 07:20 --- Created an attachment (id=12235) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12235&action=view) Fix. Patch against 4.1 branch but should apply to any 4.x trees in the ada/ subdir. Please use it locally as

[Bug c++/20420] Incorrectly Accepts double declarations

--- Comment #6 from andrew dot stubbs at st dot com 2006-09-12 07:44 --- Subject: Re: Incorrectly Accepts double declarations bangerth at dealii dot org wrote: > No, that code is definitely legal and unobjectionable. Just as having two > extern declarations of the same variable in the

[Bug c++/28820] sizeof == 0 for empty class

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-12 08:01 --- class A { public: int a[0]; }; This class is not empty, it contains a (GNU) variable sized array so the size of zero is correct for this extension. The reason why it is zero is because the array size is ze

[Bug c++/28718] Call to -lgcc added prior to user libraries

--- Comment #7 from pinskia at gcc dot gnu dot org 2006-09-12 08:06 --- (In reply to comment #6) > The suggestion of Joerg Wunsch is, thus, in line with the needs of gcc users > for the avr target. But not in the line with the rest of GCC. Really if you cannot get a patch applied to GCC

[Bug middle-end/28781] -fPIC generates non-PIC code

--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-12 08:10 --- /usr/bin/ld: ./flow/gslpp/.libs/libgslpp.a(datahandle.o): relocation R_X86_64_PC32 against `vtable for GSL::WaveDataHandle' can not be used when making a shared object; recompile with -fPIC This looks more like a b

[Bug libstdc++/29026] std::basic_istream<>::sentry() fails to catch when reading whitespace

--- Comment #6 from pcarlini at suse dot de 2006-09-12 08:28 --- Basing on Martin' comments, I think this PR should bu suspended, waiting for the outcome of DR 309 (certainly directly relevant). -- pcarlini at suse dot de changed: What|Removed |Add

[Bug libstdc++/29026] [DR 309] std::basic_istream<>::sentry() fails to catch when reading whitespace

-- pcarlini at suse dot de changed: What|Removed |Added Status|NEW |SUSPENDED Summary|std::basic_istream<>::sentry|[DR 309]

[Bug c++/28718] Call to -lgcc added prior to user libraries

--- Comment #8 from j at uriah dot heep dot sax dot de 2006-09-12 08:52 --- (In reply to comment #7) > So this is not a bug. Also if libm is only the normal math library and should > not include the soft-fp but those should be in libgcc as they are support > functions needed for GCC t

[Bug fortran/28971] ICE: Segmentation fault on valid code

--- Comment #4 from pault at gcc dot gnu dot org 2006-09-12 08:59 --- Oskar, We believe that this bug is "fixed"; however, I will take you tst.f90 and put it in the gfortran testsuite, since we do not know what moved to produce both the regression and the "fix". As I said to the list,

[Bug fortran/28993] Internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:783

--- Comment #4 from pault at gcc dot gnu dot org 2006-09-12 09:02 --- Daniel, This bug is fixed in more recent gfortrans. You will have a much easier life if you upgrade; expecially to 4.2, for which binaries are available from the gfortran wiki. If you have any difficulties with the

[Bug fortran/28809] No diagnostic for missing interface for same file procedure

--- Comment #3 from pault at gcc dot gnu dot org 2006-09-12 09:10 --- John, The ICE is fixed on recent versions of gfortran. However, I am keeping the PR and giving it a new summary because the lack of a warning on the assumed shape array is a problem that is related to others. Pleas

[Bug fortran/28971] ICE: Segmentation fault on valid code

--- Comment #5 from enok at lysator dot liu dot se 2006-09-12 09:15 --- Subject: Re: ICE: Segmentation fault on valid code Yes that's fine with me. I don't have access to the computer where I originally noticed the problem until the end of the week so I haven't been able to try any

[Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space

--- Comment #52 from hubicka at gcc dot gnu dot org 2006-09-12 10:11 --- Subject: Bug 28071 Author: hubicka Date: Tue Sep 12 10:11:04 2006 New Revision: 116886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116886 Log: PR rtl-optimization/28071 * tree-vect-tran

[Bug middle-end/29029] temporary created for unknown reason

--- Comment #2 from etienne_lorrain at yahoo dot fr 2006-09-12 11:12 --- > "X" (*str) > We need a temporary here because *str can be modified inside the asm and we > don't know that you want it in a memory or a register. *str cannot be modified inside the asm because that is an input

bug report

a bug in mingw //this shows that the older version of mingw32 can be better than the newer one #include #include #include main() { //the string should be written two times if the file exists ifstream xyz; char chr; xyz.open("a.bat"); while(xyz.get(chr)) cout<

[Bug middle-end/26635] [4.1 Regression] Bogus Storage_Error warning

--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-09-12 11:43 --- > It looks like this may be fixed on the mainline? At least the C testcase from > http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00198.html no longer shows > overflowed constants. Right, the warning has disappeare

[Bug c/29033] New: %s substituted with "left"/"right" can't be properly translated

In gcc/cp/typeck.c there is this code. if (tree_int_cst_lt (op1, integer_zero_node)) warning (0, "%s rotate count is negative", (code == LROTATE_EXPR) ? "left" : "right"); else if (compare_tree_int (op1, TYPE_PRECISION (type0)) >

[Bug other/28957] unoptimal virtual method call.

--- Comment #4 from pluto at agmk dot net 2006-09-12 12:58 --- i dont't think it's invalid report. -funswitch-loop produces only slightly better results. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28957

[Bug tree-optimization/27755] PRE confused by control flow

--- Comment #7 from dberlin at gcc dot gnu dot org 2006-09-12 13:31 --- Subject: Re: PRE confused by control flow This will be fixed by the 4.3 changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27755

[Bug other/28994] 64-bit problem in host-darwin.c

--- Comment #2 from lucier at math dot purdue dot edu 2006-09-12 14:04 --- Subject: Re: 64-bit problem in host-darwin.c I doubt that it works on x86-64 darwin, either, but I can't test it there. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28994

[Bug libstdc++/29035] New: Initialisation of std::ostringstream does not work correctly

This bug is back with gcc 4.1.1. I was told it works ok with 4.0.3 +++ This bug was initially created as a clone of Bug #9042 +++ #include #include int main() { std::ostringstream s("abcd", std::ios_base::app); s << "xy"; std::cout << s.str() << "\n"; // outputs "xycd" (instead of the

[Bug middle-end/28781] -fPIC generates non-PIC code

--- Comment #4 from hjl at lucon dot org 2006-09-12 14:49 --- This may be related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 Please provide # readelf -s --wide ./flow/gslpp/.libs/libgslpp.a | c++filt| grep "vtable for GSL::WaveDataHandle" -- hjl at lucon dot org changed:

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #1 from pcarlini at suse dot de 2006-09-12 15:08 --- *** This bug has been marked as a duplicate of 9042 *** -- pcarlini at suse dot de changed: What|Removed |Added -

[Bug libstdc++/9042] Initialisation of std::ostringstream does not work correctly

--- Comment #4 from pcarlini at suse dot de 2006-09-12 15:08 --- *** Bug 29035 has been marked as a duplicate of this bug. *** -- pcarlini at suse dot de changed: What|Removed |Added -

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #2 from pcarlini at suse dot de 2006-09-12 15:10 --- To be 100% sure, we checked again gcc4.1.1 both on x86-linux and powerc-darwin and the bug is definitely not there (anymore) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29035

[Bug c++/29033] %s substituted with "left"/"right" can't be properly translated

--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-12 15:15 --- Confirmed. Easiest is to simply remove distinguishing between left and right. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #3 from eric_jrdn2 at yahoo dot fr 2006-09-12 15:32 --- I tried this : #include #include #include using namespace std; int main(){ ostringstream ostr; ostr.str("azerty"); cout

[Bug c++/20599] variadic template support

--- Comment #2 from bkoz at gcc dot gnu dot org 2006-09-12 15:36 --- See: http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20599

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #4 from pcarlini at suse dot de 2006-09-12 15:41 --- (In reply to comment #3) > Where should I look at? I don't understand what are you looking for, really. Your snippet behaves in the correct way, per the Standard which we are implementing. Also, to repeat, the issue report

[Bug java/28892] assignment to static field not in class initializer

--- Comment #1 from tromey at gcc dot gnu dot org 2006-09-12 15:47 --- Subject: Bug 28892 Author: tromey Date: Tue Sep 12 15:47:26 2006 New Revision: 116889 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116889 Log: PR java/28892: * expr.c (expand_java_field_op):

[Bug c++/20599] variadic template support

--- Comment #3 from pcarlini at suse dot de 2006-09-12 15:50 --- Then the real issue maybe is the following: what are we going to do vs C++0x features? Shall we set-up the compiler switch for it (-std=c++0x?) and start adding things? Or people believe it's too early? Maybe a good comprom

[Bug java/28754] [4.2 regression] java.lang.nullPointerException while accessing final static members of an interface

--- Comment #7 from tromey at gcc dot gnu dot org 2006-09-12 15:55 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|AS

[Bug java/28754] [4.2 regression] java.lang.nullPointerException while accessing final static members of an interface

--- Comment #8 from tromey at gcc dot gnu dot org 2006-09-12 15:55 --- Subject: Bug 28754 Author: tromey Date: Tue Sep 12 15:55:07 2006 New Revision: 116890 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116890 Log: PR java/28754: * expr.c (expand_java_field_op):

[Bug libstdc++/29037] New: performance problem with std::string operator=(const std::string& str);

Hi, I tested the following behaviour with all gcc versions I had available (gcc 3.3.6 on x86 Slackware Linux, gcc 4.0.2 on x86 SUSE Linux, gcc 4.0.1 on OS X). The following code: std::string s1; // in the following call memory is allocated // and the capacity of s1 goes to 1024 s1.resize(1024);

[Bug middle-end/4520] cselib.c hash_rtx incorrectly hashes based on rtx address

--- Comment #9 from sayle at gcc dot gnu dot org 2006-09-12 16:02 --- Subject: Bug 4520 Author: sayle Date: Tue Sep 12 16:02:31 2006 New Revision: 116891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116891 Log: PR middle-end/4520 PR bootstrap/28784 * c

[Bug bootstrap/28784] [4.2 regression] Bootstrap comparison failure

--- Comment #7 from sayle at gcc dot gnu dot org 2006-09-12 16:02 --- Subject: Bug 28784 Author: sayle Date: Tue Sep 12 16:02:31 2006 New Revision: 116891 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116891 Log: PR middle-end/4520 PR bootstrap/28784 *

[Bug java/29013] gcj generates a MetalLookAndFeel class that fails cacao's verifier

--- Comment #4 from tromey at gcc dot gnu dot org 2006-09-12 16:05 --- "stack size too large" ... this sounds weird. I haven't looked at the .class yet however. -- tromey at gcc dot gnu dot org changed: What|Removed |Added -

[Bug java/28979] GCJ errors out when compiling .class files produced by Scala 2.1.8

--- Comment #6 from tromey at gcc dot gnu dot org 2006-09-12 16:09 --- This is fixed in svn head. Part was fixed by the mangling change, which we can't backport to 4.1. The other part was fixed when the PR 28892 fix went in today. I didn't let it try to compute the 1000th number but t

[Bug java/29013] gcj generates a MetalLookAndFeel class that fails cacao's verifier

--- Comment #5 from tromey at gcc dot gnu dot org 2006-09-12 16:13 --- Ok, I see. Cacao's message is confusing, since what it really means is that there is a stack overflow in the method: Attribute "Code", length:29, max_stack:0, max_locals:1, code_length:5 0: invokestatic #23= 3

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #5 from sebor at roguewave dot com 2006-09-12 16:16 --- (In reply to comment #4) Shouldn't the output be: 6 azerty123 9 -- sebor at roguewave dot com changed: What|Removed |Added ---

[Bug java/29013] gcj generates a MetalLookAndFeel class that fails cacao's verifier

--- Comment #6 from tromey at gcc dot gnu dot org 2006-09-12 16:25 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|u

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #1 from pcarlini at suse dot de 2006-09-12 16:30 --- Let's think a bit more about this issue, without forgetting, however, that our default (*) string class is *reference counted*: that means that upon s1=s2 the string s2 is *not* actually copied, only the reference count upd

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #6 from pcarlini at suse dot de 2006-09-12 16:33 --- (In reply to comment #5) > (In reply to comment #4) > > Shouldn't the output be: > > 6 > azerty123 > 9 In case, that would be a separate issue, we never considered implementing that behavior. It would be easy, of course.

[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite

--- Comment #2 from sje at cup dot hp dot com 2006-09-12 16:36 --- I wonder if it would be possible to implement something like 'dg-timeout 600' so that the timeout could be changed for just some tests and possibly just on some hosts by using the target option with dg-timeout. Most of t

[Bug java/28892] assignment to static field not in class initializer

--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-12 16:41 --- Fix checked in. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|AS

[Bug c++/29038] New: missing diagnostic for initializer with non-matching language linkage

The following testcase should elicit a diagnostic: extern "C++" int f (int i); extern "C" { typedef int (*T) (int i); } T p = f; The C++ standard section 7.5 clause 1 says that functions with different language linkages are not the same type, and so one cannot be assigned to the other, even i

[Bug libffi/23935] $PREFIX/include/ffi.h needs to go to a target- and -version-dependent location

--- Comment #1 from daney at gcc dot gnu dot org 2006-09-12 16:51 --- Subject: Bug 23935 Author: daney Date: Tue Sep 12 16:51:43 2006 New Revision: 116893 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116893 Log: PR libffi/23935 * include/Makefile.am: Install bo

[Bug libffi/23935] $PREFIX/include/ffi.h needs to go to a target- and -version-dependent location

--- Comment #2 from daney at gcc dot gnu dot org 2006-09-12 16:54 --- Fixed by the patch I just committed. -- daney at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/29038] missing diagnostic for initializer with non-matching language linkage

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 16:55 --- *** This bug has been marked as a duplicate of 2316 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/2316] g++ fails to overload on language linkage

--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-12 16:55 --- *** Bug 29038 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #7 from pcarlini at suse dot de 2006-09-12 16:55 --- (In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > > Shouldn't the output be: > > > > 6 > > azerty123 > > 9 > > In case, that would be a separate issue, we never considered implementin

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #2 from neundorf at kde dot org 2006-09-12 17:04 --- The use case here is as follows: std::string cacheKey; cacheKey.resize(4*1024); for (...several files...) { cacheKey=current.FileName; // <- this is the critical line for(std::vector::const_iterator i = this->I

[Bug middle-end/4520] cselib.c hash_rtx incorrectly hashes based on rtx address

--- Comment #10 from pinskia at gcc dot gnu dot org 2006-09-12 17:11 --- Fixed, finally. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added C

[Bug bootstrap/28784] [4.2 regression] Bootstrap comparison failure

--- Comment #8 from pinskia at gcc dot gnu dot org 2006-09-12 17:11 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug target/22223] New testsuite failure on Tru64 UNIX V5.1B: gcc.c-torture/compile/20050622-1.c

--- Comment #2 from sayle at gcc dot gnu dot org 2006-09-12 17:14 --- Subject: Bug 3 Author: sayle Date: Tue Sep 12 17:13:55 2006 New Revision: 116895 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116895 Log: PR target/3 * config/alpha/alpha.c (alpha_st

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #8 from sebor at roguewave dot com 2006-09-12 17:24 --- No, I'm not sure. I got the output with our implementation but the latest working paper doesn't seem to support it (I had misread the text in 27.7.1.2, p2 to require that pptr() == epptr() uncoditionally rather than just

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #3 from pcarlini at suse dot de 2006-09-12 17:31 --- Yes, I understand. But consider another scenario were, after the initial assignment, you are not adding anything more later on (in the loop, in your case): doing a shallow copy (changing only the reference count) means a su

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #9 from pcarlini at suse dot de 2006-09-12 17:33 --- (In reply to comment #8) > Sorry for the noise. Your feedback is always welcome, really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29035

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #4 from pcarlini at suse dot de 2006-09-12 17:38 --- If it's not sufficiently obvious: a reserve on cacheKey *after* cacheKey=current.FileName; much better only after having checked that the vector is not empty, would be exactly as effective as the c_str workaround (as usual,

[Bug libstdc++/29035] Initialisation of std::ostringstream does not work correctly

--- Comment #10 from sebor at roguewave dot com 2006-09-12 17:44 --- I think you're right. Even my own issue 562 is clear on this. I must have a bug in the implementation of the resolution of the issue. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562 -- http://gcc.gn

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #5 from neundorf at kde dot org 2006-09-12 17:55 --- std::string cacheKey; for (...several files...) { cacheKey=current.FileName; cacheKey.reserve(4*1024); for(std::vector::const_iterator i = this->IncludePath->begin(); i != this->IncludePath->end(); ++i) {

[Bug middle-end/28493] [4.1/4.2 Regression] Wrong address of stack object used for destructor call on PPC

--- Comment #20 from jason at gcc dot gnu dot org 2006-09-12 18:02 --- Subject: Bug 28493 Author: jason Date: Tue Sep 12 18:02:36 2006 New Revision: 116900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116900 Log: PR middle-end/28493 * builtins.c (expand_builtin

[Bug c++/20599] variadic template support

--- Comment #4 from doug dot gregor at gmail dot com 2006-09-12 18:27 --- It's a chicken-and-egg problem. Nobody on the committee wants to standardize anything that isn't "existing practice," but we only want to accept patches for features that have been written into the current working

[Bug c++/20599] variadic template support

--- Comment #5 from pinskia at gcc dot gnu dot org 2006-09-12 18:29 --- Suspending untill this is accepted. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/29039] New: implicitly defined constructor for class with reference member

The following ill-formed code is accepted: typedef struct { int &r; } S; S f () { return S (); } 12.1 ; 5 states that if there is no user-declared constructor for a class, a default constructor is implicitly declared. 12.1 ; 7 states that such a constructor is implicitly defined when it is

[Bug java/29013] gcj generates a MetalLookAndFeel class that fails cacao's verifier

--- Comment #7 from tromey at gcc dot gnu dot org 2006-09-12 19:01 --- Subject: Bug 29013 Author: tromey Date: Tue Sep 12 19:00:48 2006 New Revision: 116902 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116902 Log: gcc/java PR java/29013: * jcf-write.c (generate

[Bug java/29013] gcj generates a MetalLookAndFeel class that fails cacao's verifier

--- Comment #8 from tromey at gcc dot gnu dot org 2006-09-12 19:01 --- Fix checked in. I probably won't backport this to the 4.1 branch but I would not object if someone else wanted to. -- tromey at gcc dot gnu dot org changed: What|Removed |Added

Problem with inheriting from partial specialization

Dear gcc-bugs-mailinglist, I'm having a problem with inheriting from a partial specialization of a class, and in particular using a public templatized instance variable of the partial specialization. I've genericized the code with somebody else to the following reduction which shows the essence o

[Bug c++/29039] [4.0/4.1/4.2 Regression] implicitly defined constructor for class with reference member

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 19:08 --- Even though we give a weird error message in 3.4.0 and before, we rejected the code: t.cc: In function `struct S f()': t.cc:11: no matching function for call to `S::._0 ()' t.cc:6: candidates are: S::._0(const S &)

Re: Problem with inheriting from partial specialization

> > Dear gcc-bugs-mailinglist, > > I'm having a problem with inheriting from a partial specialization of > a class, and in particular using a public templatized instance > variable of the partial specialization. I've genericized the code with > somebody else to the following reduction which shows

[Bug fortran/28971] ICE: Segmentation fault on valid code

--- Comment #6 from pault at gcc dot gnu dot org 2006-09-12 19:38 --- Subject: Bug 28971 Author: pault Date: Tue Sep 12 19:38:48 2006 New Revision: 116904 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116904 Log: 2006-09-12 Paul Thomas <[EMAIL PROTECTED]> PR fortran/

[Bug java/28089] jc1 miscompilation with fields inherited from interfaces

--- Comment #3 from tromey at gcc dot gnu dot org 2006-09-12 19:41 --- Also fixed on trunk; updating target milestone. -- tromey at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug rtl-optimization/28965] distribute_notes fails to change REG_DEAD into REG_UNUSED notes for global registers

--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-09-12 20:00 --- > The invalid REG_DEAD note triggered an ICE during sched1 with a 4.1.1 > based compiler with ENABLE_CHECKING set, compiling for sh4-elf with -O2 > -fno-exceptions. > > I can replicate the invalid REG_DEAD note wi

[Bug c++/29040] New: missing access control checks in subclasses for nested types

The following should not compile: struct c { private:struct n { int j; }; }; struct d:public c { void f (struct n *p); }; According to 9.2 ; 1, nested types are class members. 11 ; 4 says that member access control does not affect visibility, only access. If an inaccessible member name

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #6 from pcarlini at suse dot de 2006-09-12 20:18 --- (In reply to comment #5) > Why would this be faster ? Just try... > The resize() happend only once at the beginning, before the iteration starts. > And even with the reserve(), the reserve() would happen everytime before

[Bug c++/29041] New: failure to check for visible declaration of friend function to local class

The following code should not compile: int f(int); void g() { class C { friend int f(int); }; } The C++ standard clause 11.4 ; 9 states that friend declarations in local classes have different rules to friend declarations in regular classes. Friend functions must be previously declared in

[Bug target/29042] New: Useless floating-point stores and loads on x86

This is the same testcase as PR26778. This bug is marked as resolved, and the patch indeed prevents GCC from using useless mmx registers. Concerning integer operations, the generated assembly got even better than GCC 3.4, as the values are directly incremented in memory instead of being loaded and

[Bug c++/20599] variadic template support

--- Comment #6 from pcarlini at suse dot de 2006-09-12 20:30 --- For the record, personally and for what is worth my personal opinion in the compiler area, I have nothing against adding to the compiler -std=c++0x and start adding things, in general. I'm also finding a little "adventurous

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #7 from neundorf at kde dot org 2006-09-12 20:34 --- ... > "problematic" are string assigns, not += and you are moving the reserve > *after* the assign. Yes, but in the every assign the capacity would still be lost. This would mean the reserve would happen once after each a

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #8 from pcarlini at suse dot de 2006-09-12 20:45 --- (In reply to comment #7) > ... > > "problematic" are string assigns, not += and you are moving the reserve > > *after* the assign. > > Yes, but in the every assign the capacity would still be lost. This would mean > the r

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #9 from neundorf at kde dot org 2006-09-12 20:51 --- > > Starting to think about weird hacks: > > how about keeping the shared-data during string assignment as it is now > > but additionally keep a pointer to the eventually already allocated buffer > > around, > > so that it

[Bug c++/29040] missing access control checks in subclasses for nested types

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 20:59 --- Confirmed, not a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug libstdc++/29037] performance problem with std::string operator=(const std::string& str);

--- Comment #10 from pcarlini at suse dot de 2006-09-12 21:01 --- (In reply to comment #9) > > I see this point too, I have been thinking about something along those > > lines, but you understand that we have an ABI, which we *must* keep > > absolutely stable, > > Yes, I understand. > B

[Bug c++/29043] New: Constructor for POD type with const member without member initializer accepted

The following C++ code should not compile: class C { C() { } struct s { const int i; }; }; The C++ standard clause 12.6.2 ; 4 says that for each non-static data member of a POD class type containing a member of a const-qualified type, there must be a member initialiser, or else the pro

[Bug java/29044] New: Libiberty demangler can not handle new Java mangling.

In earlier versions of GCJ this: public class jmain { public static void main (String[] args) { return; } } Was mangled to: _ZN5jmain4mainEP6JArrayIPN4java4lang6StringEE Now it is mangled to: _ZN5jmain4mainEJvP6JArrayIPN4java4lang6StringEE (Including Jv, for a void return t

[Bug java/29044] Libiberty demangler can not handle new Java mangling.

--- Comment #1 from drow at gcc dot gnu dot org 2006-09-12 21:43 --- Unless this turns out to be a mangling problem, I assume it's a libiberty/demangler problem. -- drow at gcc dot gnu dot org changed: What|Removed |Added --

[Bug rtl-optimization/28243] [4.1 Regression] internal consistency failure when building fontforge with -O3 -fPIC -ftracer

--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-12 21:48 --- Subject: Bug 28243 Author: ebotcazou Date: Tue Sep 12 21:48:40 2006 New Revision: 116906 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116906 Log: PR rtl-optimization/28243 * combine.c (d

[Bug rtl-optimization/28243] [4.1 Regression] internal consistency failure when building fontforge with -O3 -fPIC -ftracer

--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-09-12 21:49 --- Subject: Bug 28243 Author: ebotcazou Date: Tue Sep 12 21:49:45 2006 New Revision: 116907 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116907 Log: PR rtl-optimization/28243 * combine.c (d

[Bug rtl-optimization/28243] [4.1 Regression] internal consistency failure when building fontforge with -O3 -fPIC -ftracer

--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-09-12 21:54 --- Fixed in upcoming 4.1.2 release. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/29045] New: gcc fails to compile code with operator delete(void*,size_t)

The problems described in bug 27935 also affect gcc 4.0.3, making it impossible for me to build several pieces of software that built just fine under previous versions of gcc. mysql and octave are two examples. -- Summary: gcc fails to compile code with operator d

[Bug c++/29046] New: Failure to define friend functions for all template instatiations

The following code should not compile: template struct C { friend void f (C *) { char a[sizeof(T)-1]; // { dg-error "ISO C++ forbids zero-size array" } } void g (C *t) { f (t); } }; C x; The C++ standard clause 14.5.3; 5 states that friend function definitions (as opposed t

[Bug c++/29045] gcc fails to compile code with operator delete(void*,size_t)

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 22:11 --- Can you attach the preprocessed source? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/29046] Failure to define friend functions for all template instatiations

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 22:17 --- Related to PR 19809, I think this actually is fixed now. Can ou report what version of 4.2.0 which you are using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29046

[Bug c++/29048] New: "`x' is private" error duplicated when scope specified

Given file `ptest.cpp': class A {int i;}; class B : public A {B() {A::i=0;}}; I get (with quotes replaced with ASCII and some bijective directory simplification) $ g++ -v ptest.cpp Reading specs from /opt/local/gcc402/bin/../lib/gcc/i686-pc-linux-gnu/4.0.2/specs Target: i686-pc-linux-gnu Configu

[Bug c++/29045] gcc fails to compile code with operator delete(void*,size_t)

--- Comment #2 from quanah at stanford dot edu 2006-09-12 22:30 --- Created an attachment (id=12237) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12237&action=view) preprocessed source Here is the preprocessed source. Here's the error: backports:/afs/ir/src/pubsw/data/octave-2.

[Bug c++/29048] [4.0/4.1/4.2 Regression] "`x' is private" error duplicated when scope specified

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-12 22:32 --- Related to PR 19375. Confirmed, a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c++/29046] Failure to define friend functions for all template instatiations

--- Comment #2 from amylaar at gcc dot gnu dot org 2006-09-12 22:45 --- (In reply to comment #1) > Related to PR 19809, I think this actually is fixed now. > Can ou report what version of 4.2.0 which you are using? > GNU C++ version 4.2.0 20060823 -- http://gcc.gnu.org/bugzilla/sh

[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite

--- Comment #3 from janis at gcc dot gnu dot org 2006-09-12 23:23 --- I'm starting to figure out how all this works. A quick fix for now might be, as Benjamin suggested, for libstdc++.exp to only change the timeout value if it doesn't already exist. That could be done with if [tar

[Bug libfortran/27964] Wrong line ends on windows (XP)

--- Comment #9 from dannysmith at users dot sourceforge dot net 2006-09-12 23:36 --- The problem is that although all 'regular' files are opened as O_BINARY, preconnected files stderr and stdout are already opened as default O_TEXT. The simplest fix is just to force the mode of these

[Bug testsuite/28870] [4.2 Regression] configuring, over-riding timeout values in testsuite

--- Comment #4 from janis at gcc dot gnu dot org 2006-09-12 23:42 --- Mike, I added you to the cc: list because you know a lot about how DejaGnu is used with the GCC testsuite and undoubtedly have useful things to add to the discussion. -- janis at gcc dot gnu dot org changed:

  1   2   >