In the following code, the private member `n' of class `C' can be accessed by
derived class `D'.
The fact that g++ does not complain depends on the order of the declarations.
Typically, moving the `C::n' initialization elsewhere in the code will trigger
(as expected) the following error:
$ error:
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
--- Additional Comments From radford at indigita dot com 2005-05-21 02:55
---
Possibly duplicates bug 20810.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
There are failures on the libjava testsuites for sh4-unknown-linux-gnu
FAIL: Class_1 execution - source compiled test
FAIL: Class_1 execution - bytecode->native test
FAIL: Class_1 -O3 execution - source compiled test
FAIL: Class_1 -O3 execution - bytecode->native test
FAIL: InvokeInterface executi
--
What|Removed |Added
Known to fail||3.4.1 3.4.4
Known to work||3.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Additional Comments From radford at indigita dot com 2005-05-21 02:45
---
Created an attachment (id=8941)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8941&action=view)
file that triggers the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21691
The following fails, while adding -fno-inline or -O[012345] or removing -mthumb
or reverting to 3.3.2 makes it work.
$ arm-elf-gcc -c -mthumb -Os arm-thumb-Os-inline-bug.c
arm-thumb-Os-inline-bug.c: In function `show':
arm-thumb-Os-inline-bug.c:24: error: insn does not satisfy its constraints:
(i
I have a laptop with pentium M centrino 1.7 ghz cpu, 512 mb ram, suse linux
prof. 9.2 operating
system (with all possible patches installed), and gcc (GCC) 3.3.4 (pre 3.3.5
20040809).
I downloaded gcc-3.4.4 full source code from one of the mirrors specified at
gcc.gnu.org, and
extracted the .ta
Hello. Your mail to boris cannot be delivered because that person is
no longer here. Your message appears to have been directed to the following
address(es):
[EMAIL PROTECTED]
However, we have a new address for boris:
[EMAIL PROTECTED]
You should redirect your mail to this n
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-05-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21
00:32 ---
This bolls down to combine not working across function calls. The correct way
to fix this would to have
a tree combiner.
--
What|Removed |Added
---
--- Additional Comments From guptan at hotmail dot com 2005-05-21 00:28
---
Thanks Andrew.
[17:00] pinskia, yes I am trying to get an answer if PR21616 existed on
gcc-4.0 :)
[17:01] it might be worked around by optimizing it better :)
[17:01] I suspect its already fixed in rs6000.md,
hi, i'm using Debian SID experimental gcc-4.0
gcc-4.0 -v
Using built-in specs.
Target: powerpc-linux
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gette
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21
00:19 ---
The work around for PR 13674 in the 3.4 branch is trying to use a FP register
as that is what the work
around says to do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21
00:14 ---
This was really fixed on the mainline by:
2005-01-07 David Edelsohn <[EMAIL PROTECTED]>
PR target/13674
* config/rs6000/rs6000.c (rs6000_legitimize_reload_address):
Convert non-wor
--- Additional Comments From falk at debian dot org 2005-05-20 23:20
---
(In reply to comment #0)
> If there is a variable declaration as the first statement after the colon at
> the
> end of a case expression, the compiler returns a syntax error.
That is exactly as expected. After the
--- Additional Comments From dave at boost-consulting dot com 2005-05-20
23:12 ---
Subject: Re: [4.0/4.1 Regression] Internal Compiler Error
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
> 19
If there is a variable declaration as the first statement after the colon at the
end of a case expression, the compiler returns a syntax error. If there any
statements between the case expression and the variable declaration then it will
not produce an error, a partial list of the statements that I
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
23:02 ---
Oh, even at -O0 -funit-at-a-time, we get this missed compiled.
There are buffer overflows somewhere:
***
mudflap violation 1 (check/write): time=1116629904.932813 ptr=0x80ce540 size=33
pc=0x45b4a8 locat
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-20
22:52 ---
Fixed in 4.0.
--
What|Removed |Added
Status|NEW |RESOLVE
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-20
22:52 ---
Subject: Bug 19016
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-20 22:51:46
Modified files:
libgfortran: Change
I know this goes against all the rules for filing bugs but when I supply
-save-temps, I don't get an ICE.
The code is the code from PR 21685 with one exception, the following 2 lines
are commented out (this
makes this code valid):
const value_iterator end = union_f(sets.begin(), se
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
21:42 ---
Confirmed, reduced testcase:
template
struct g
{
int operator()(int i){return i;}
};
template
struct h
{
int f(void)
{
g i;
struct f1
{
int f(void){return i(0);}
};
f1 aa;
--
What|Removed |Added
Known to fail||4.0.0 4.1.0
Known to work||3.4.0
Target Milestone|---
Take the following code (which I found while reducing PR 21685):
template
int f(void)
{
int i;
struct f1
{
int f(void){return i;}
};
}
We get:
t1.cc: In member function 'int f()::f1::f()':
t1.cc:7: error: use of % variable from containing function
t1.cc:4: error: 'int i' declared he
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-05-20
21:35 ---
I think the first of those is the best. Tested on i386-mingw32.
--
What|Removed |Added
--- Additional Comments From o dot kullmann at swansea dot ac dot uk
2005-05-20 21:30 ---
Oh, yes, I did overlook that I had to pass also that object union_f
as parameter --- thanks for telling me! Now the code compiles again.
So it's an "internal compiler error on incorrect code".
-
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-05-20 21:17 ---
A patch was submitted here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01794.html
and a different one here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02074.html
Danny
--
http://gcc.gn
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
21:16 ---
This code is invalid, you are trying to use union_f in an "inner" class but
unlike Java, "inner" classes in
C++, you cannot access the outer class's members.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
On g++ versions 3.4.3, 3.4.4 and 4.0.0 the following code
#include
#include
#include
#include
#include
#include
#include
namespace OKlib {
namespace TestSystem {
typedef unsigned int LineNumber;
cl
--
What|Removed |Added
Component|c |target
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
/opt/winchester/mcore/mcore-elf/bin/mcore-elf-gcc-4.0.0 -v --save-temps
lshrdi-1.c
Using built-in specs.
Target: mcore-elf
Configured with: ../../src/gcc/gcc-4.0.0/configure --target=mcore-elf
--prefix=/opt/winchester/mcore/mcore-elf/ --enable-languages=c --with-newlib
Thread model: single
gcc ver
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-20
20:03 ---
I've checked in a patch to the 4.0 branch.
A different approach seems best for the trunk,
so I'm going to leave the PR open until I write that.
--
What|Removed |Added
---
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-20
20:02 ---
Subject: Bug 21637
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-20 20:02:16
Modified files:
libjava: Change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
19:59 ---
(In reply to comment #5)
> The code is definitely invalid; I was just wondering how you decided that so
> quickly ;-)
I looked into the source and found where it crashing. It was obvious from
where the cr
--- Additional Comments From dave at boost-consulting dot com 2005-05-20
19:56 ---
The code is definitely invalid; I was just wondering how you decided that so
quickly ;-)
It still should never cause an ICE, of course ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
19:27 ---
Maybe not.
But in 3.4.0, I do get a warning:
copy.cpp: In function `int test_main(int, char**)':
copy.cpp:25: error: no match for call to `(const
boost::sequence::algorithm::copy_) (const boost::
array&, bo
--- Additional Comments From mark at codesourcery dot com 2005-05-20 18:48
---
Subject: Re: libstdc++ headers should have pop/push
of the visibility around the declarations
lanius at gentoo dot org wrote:
> --- Additional Comments From lanius at gentoo dot org 2005-05-20 08:35
>
The following patch causes a build failure on i386-mingw:
2005-05-15 Gabriel Dos Reis <[EMAIL PROTECTED]>
* fixincl.c: #include
Build was successful before, but now fails when compiling fixincl.c, since MinGW
doesn't have a sys/wait.h headers file. With this #include statement removed,
--- Additional Comments From dank at kegel dot com 2005-05-20 18:05 ---
http://sources.redhat.com/ml/crossgcc/2005-05/msg00154.html
is a report of a similar problem with
gcc-3.4.3. xfree86-4.5.0's fontutils.c causes an ICE when
compiled with -O3 -fno-strict-aliasing. Backing down to xf
--- Additional Comments From dave at boost-consulting dot com 2005-05-20
18:05 ---
(In reply to comment #2)
> This code is invalid.
How did you come to that determination?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
--- Additional Comments From guptan at hotmail dot com 2005-05-20 17:43
---
Alan, Andrew,
If any one of you have setup with gcc-4.0 handy, could you verify if this bug
exists there as well?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21616
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-05-20
17:42 ---
Also fixed in 4.0.1.
--
What|Removed |Added
Target Milestone|4.1.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-20
17:33 ---
This code is invalid.
--
What|Removed |Added
Severity|critical
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-20
17:29 ---
Subject: Bug 1016
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-20 17:28:56
Modified files:
gcc/cp : cp-tree
--- Additional Comments From hubicka at ucw dot cz 2005-05-20 17:22 ---
Subject: Re: [4.1 regression] ICE using -ftree-vectorize
>
> --- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-20
> 16:56 ---
> The problem disappeared with Jan Hubicka's patch
> http:/
--- Additional Comments From dave at boost-consulting dot com 2005-05-20
17:13 ---
Created an attachment (id=8939)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8939&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
GCC reports
../../../../boost/sequence/begin.hpp:53: error: 'begin' is already declared in
this scope
When creating an overload set by bringing a function into a namespace via
using-declaration. Compile the enclosed source to demonstrate.
--
Summary: Disallowed using declaration
--- Additional Comments From dave at boost-consulting dot com 2005-05-20
17:08 ---
Created an attachment (id=8938)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8938&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
Compile the enclosed source for an ICE
--
Summary: Internal Compiler Error
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-20
16:56 ---
The problem disappeared with Jan Hubicka's patch
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00805.html
Is the patch a proper fix (i.e. can we close the PR)
or does it only paper over the problem?
--
--- Additional Comments From giovannibajo at libero dot it 2005-05-20
15:50 ---
Notice that both testcases come from the same program (Gujin).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
--- Additional Comments From giovannibajo at libero dot it 2005-05-20
15:49 ---
*** Bug 21680 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21529
--- Additional Comments From giovannibajo at libero dot it 2005-05-20
15:49 ---
A duplicate of 21529. I have attached this testcase into that bug.
*** This bug has been marked as a duplicate of 21529 ***
--
What|Removed |Added
---
--- Additional Comments From dave at boost-consulting dot com 2005-05-20
15:38 ---
Subject: Re: Download > Releases doesn't take me to appropriate info
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
> --- Additional Comments From pcarlini at suse dot de 2005-05-20 15:20
>
This stripped down extract of a real file (main.c of Gujin-1.1 in
sourceforge) gives:
$ gcc -Os tst.c -c -o tst.o && size tst.o
textdata bss dec hex filename
261 0 0 261 105 tst.o
$ ../toolchain/bin/gcc -Os tst.c -c -o tst.o && size tst.o
textdat
--- Additional Comments From pcarlini at suse dot de 2005-05-20 15:20
---
Hi Dave: I think you have point. What I find misleading is so much space devoted
to GCC Timeline - in the Download page - and only one line (on top, ok...)
redirecting to the list of mirrors (actually holding the
If I wanted to download a GCC release, I'd follow the link under Download
labelled "releases," but that link doesn't lead to any information about how to
download a release or any links that lead to releases.
--
Summary: Download > Releases doesn't take me to appropriate info
--- Additional Comments From pcarlini at suse dot de 2005-05-20 13:50
---
I see. I tried both stock 2.15 and 2.16, no problems...
--
What|Removed |Added
Status|W
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-05-20
13:36 ---
The original testcase and the testcase from comment #2 compile on mainline.
The underlying ABI problem still remains, however.
The following updated testcase still gives assembler errors on mainline:
--- Additional Comments From oms at home dot nl 2005-05-20 13:14 ---
2.15. It's an up-to-date debian testing install, nothing special.
# ld --version
GNU ld version 2.15
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms o
--- Additional Comments From pcarlini at suse dot de 2005-05-20 13:01
---
Can be related to 20979, fixed for 4.0 and mainline. Still cannot reproduce.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
--- Additional Comments From pcarlini at suse dot de 2005-05-20 12:54
---
I cannot reproduce the problem: besides, we have simple testcases in our
testsuite for this usage and we have no problems on many different
architectures.
Which version of binutils are you using?
--
W
There is a weird interaction in using both inline and always_inline:
=
static inline __attribute__((always_inline)) int foo(int a)
{
if (a==0)
return 0;
}
=
Compiling wit
--- Additional Comments From oms at home dot nl 2005-05-20 12:25 ---
Created an attachment (id=8936)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8936&action=view)
test source 2 of 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
--- Additional Comments From oms at home dot nl 2005-05-20 12:24 ---
Created an attachment (id=8935)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8935&action=view)
test source 1 of 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21677
Compiling the two following trivial files together causes link-time errors due
to multiply-defined symbols in bitmap_allocator.h. What am I missing here?
// t.cc
#include
int main ()
{
}
// EOF
// t1.cc
#include
// EOF
$ /usr/local/gcc-3.4.4/bin/g++ -v -save-temps t.cc t1.cc
Reading specs fro
--- Additional Comments From cognot at earthdecision dot com 2005-05-20
10:03 ---
(In reply to comment #59)
>
> I had this bug on x86 architecture, with no optimization of the code (no -OX)
> and with float-store on. My workaround was to store the return of the double
> function in a au
--- Additional Comments From giovannibajo at libero dot it 2005-05-20
09:54 ---
A patch was posted by Richard Sandiford:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02029.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21638
--- Additional Comments From pcarlini at suse dot de 2005-05-20 09:03
---
FWIW, I agree, as far as the visibility issues are concerned (I don't want to
say something more general): the issues are *long* standing, important projects
are already using the features and nobody (almost ;) car
--- Additional Comments From pluto at agmk dot net 2005-05-20 09:02 ---
(In reply to comment #52)
> Great! I forgot to thank you for all your testing efforts: thanks! (...)
i'll test these fixes on alpha/sparc{32,64} too in near feature.
i have machines but no time :/
--
http:
--- Additional Comments From pluto at agmk dot net 2005-05-20 08:58 ---
(In reply to comment #54)
> Subject: Re: libstdc++ headers should have pop/push
> of the visibility around the declarations
>
> bernie at develer dot com wrote:
>
> > It's not a regresion, but it causes KDE
--- Additional Comments From mario dot tragni at planetek dot it
2005-05-20 08:40 ---
(In reply to comment #2)
> State-Changed-From-To: open->closed
> State-Changed-Why: See any faq on numerical analysis that mentions the x86.
> You are seeing the results of excess precision in the F
--- Additional Comments From lanius at gentoo dot org 2005-05-20 08:35
---
no workaround, the flag was just disabled on the affected architectures
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Additional Comments From jbucata at tulsaconnect dot com 2005-05-20
08:34 ---
Created an attachment (id=8933)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8933&action=view)
preprocessed testcase files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21676
I see a 14% slowdown with the SciMark sparse matrix multiplication benchmark
when going from 3.4.3 to 4.0.0 on my Gentoo box. Flags are -O3 -march=athlon-xp
-fomit-frame-pointer. I compiled and linked in one run of gcc, and ran the
executable from the command line with "time".
4.0's performance
--- Additional Comments From falk at debian dot org 2005-05-20 07:43
---
It's slightly improved now on mainline, but still an unneccesary branch:
le1_bit: lda v0,1
lda t0,-1(a0)
beq a0,L1
and a0,t0,t0
cmpeq t0,0,v0
L1: ret
--
78 matches
Mail list logo
