--- Comment #2 from emilp at mac dot com 2006-03-08 08:45 ---
But isn't this problem already solved for the "using" directive. The code below
compiles fine and works as expected. In fact, in the days of gcc 3, "using"
could be used for namespaces and behaved exactly the way I would prefe
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:29
---
Confirmed on gcc mailing-list.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:51
---
This was fixed on rev. 110700 for trunk, and later backported to 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:55
---
(In reply to comment #23)
> I think MIPS16, FRV and US_SOFTWARE_GOFAST still need fixing. (The last
> quite likely by removing US_SOFTWARE_GOFAST support.)
Adding the maintainers of all those in Cc list. I don
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:57
---
(In reply to comment #4)
> Interesting darwin-fallback.c got the fix:
> 2005-03-25 Geoffrey Keating <[EMAIL PROTECTED]>
>
> * config/rs6000/darwin-fallback.c: Don't include .
> Use our own struc
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-08 10:18 ---
For mainline, this is a dup of 26449. For 4.1.0 I can reproduce this:
#1 0x08493eae in push_reload (in=0x4023a4b8, out=0x40241280,
inloc=0x40244a84, outloc=0x40229be0, class=NO_REGS, inmode=V4SImode,
out
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-08 10:40 ---
(gdb) call debug_rtx(*outloc)
(subreg:TI (reg:V4SI 23 xmm2 [99]) 0)
(but of course it looks like NO_REGS doesn't make any sense for this reload)
(gdb) up
#2 0x0849b343 in find_reloads (insn=0x402401b8, replace=0,
--- Comment #6 from rmathew at gcc dot gnu dot org 2006-03-08 11:40 ---
(In reply to comment #5)
> Confirmed on gcc mailing-list.
Reconfirmed with the GCC 4.1.0 release tarballs for C (core)
and C++ (g++). In addition to using "--with-ld", one has to
also use a relative path to the "con
when compiling
class A{
class B{}
}
class C extends A.B{}
with
gcj -S
compiler crashes
author of report
Marek Warpechowski [EMAIL PROTECTED]
--
Summary: compiler crashes "segmentation fault"
Product: gcc
Version: unknown
the code:
class A{
public:
A(int i){}
};
int main(){
A *a=new A[10](2);
int *p=new int[10](3);
}
--
2 problems:
1. This code compiles with g++ -Wall -ansi (no warning)
put I think that array initialisation is
forbidden in ANSI (the comp
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 12:39 ---
So it looks like this is HWI bug really, if a target needs to support TImode in
any shape or form, HWI should be set to 64bits no questions asked.
--
pinskia at gcc dot gnu dot org changed:
What|R
--- Comment #3 from neil at fnxweb dot com 2006-03-08 12:41 ---
Was it compiled up to use mt_allocator? I won't have the time to check again
for a short while.
If it's considered a good idea to use -pthreads, then it ought really to have
it's info-page entry updated to not make it plat
--- Comment #6 from belyshev at depni dot sinp dot msu dot ru 2006-03-08
12:46 ---
This bug prevents emacs from working, it says "M-x is undefined".
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 12:50 ---
This "works" for me by rejecting with -Wall -ansi:
pc64:~> ~/gcc-4.0/bin/gcc t2.cc -W -Wall -ansi
t2.cc:3: warning: unused parameter i
t2.cc: In function int main():
t2.cc:7: error: ISO C++ forbids initialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 12:59 ---
This is invalid code as you cannot use A.B outside of A as it is not a static
inner class.
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 13:00 ---
This is a dup of bug 18130.
*** This bug has been marked as a duplicate of 18130 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 13:00 ---
*** Bug 26603 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
EDG-based compilers accept (in strict mode) accept this:
template
struct is_void
{ static const bool value = false; };
template<>
struct is_void
{ static const bool value = true; };
template
struct enable_if { };
template
struct enable_if
{ typedef T type; };
namespace one
{
te
--- Comment #1 from pcarlini at suse dot de 2006-03-08 13:57 ---
Actually, the issue seems much simpler:
namespace one
{
template
void
fun(T);
}
using one::fun;
template
void
fun(T);
paolo:~/Work> g++ -c reduced2.cc
reduced2.cc:12: error: 'template void fu
--- Comment #2 from pcarlini at suse dot de 2006-03-08 14:01 ---
Likely a duplicate of c++/21682, but simpler testcase ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 14:07 ---
(In reply to comment #2)
> Likely a duplicate of c++/21682, but simpler testcase ;)
I don't know how that and comment #1 are valid code as in both cases the
arguments will be the same so you should get an error abou
--- Comment #4 from pcarlini at suse dot de 2006-03-08 14:11 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Likely a duplicate of c++/21682, but simpler testcase ;)
>
> I don't know how that and comment #1 are valid code as in both cases the
> arguments will be the same so
--- Comment #5 from pcarlini at suse dot de 2006-03-08 14:15 ---
(In reply to comment #4)
> > I don't know how that and comment #1 are valid code as in both cases the
> > arguments will be the same so you should get an error about ambiguous
> > functions.
>
> Not so early, I think, beca
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-08 14:21 ---
(In reply to comment #5)
> And, by the way, this one already compiles:
But that names the same function, it is just like:
int f(void);
int f(void);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
--- Comment #7 from pcarlini at suse dot de 2006-03-08 14:24 ---
(In reply to comment #6)
> (In reply to comment #5)
> > And, by the way, this one already compiles:
> But that names the same function, it is just like:
> int f(void);
> int f(void);
No, it's not the same, because we are d
--- Comment #2 from aph at gcc dot gnu dot org 2006-03-08 14:35 ---
I've started some experimental work on this at
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-abi-experimental-branch.
Initial improvements in grabage collection time are encouraging, but there are
some problems with po
--- Comment #11 from greenrd at gcc dot gnu dot org 2006-03-08 14:39
---
Sorry, I can't submit patches to libjava because I'm tainted (except for the
packages that are new in Mustang, which I haven't seen). Even though this is a
small change, I prefer to err on the side of caution.
--
--- Comment #8 from pcarlini at suse dot de 2006-03-08 14:56 ---
(In reply to comment #7)
> No, it's not the same, because we are dealing with the templates. I'm going to
> study the standard (maybe you can also do that ;) but we have an hard fact:
> both g++ and EDG accept the version w
--- Comment #7 from bangerth at dealii dot org 2006-03-08 14:57 ---
(In reply to comment #6)
> We don't use pre-compiled headers ourselves. Any precompiles are third-party
> or
> standard library, and actually I was unaware that they were used. Can you tell
> me the files that the heade
--- Comment #3 from bangerth at dealii dot org 2006-03-08 14:59 ---
I didn't make up the rules, so you're barking up the wrong tree :-)
But the difference between using directives for names and namespace
aliases is that a using directive is final: it imports a name into
the present name
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-08 15:03 ---
Subject: Bug 24183
Author: tromey
Date: Wed Mar 8 15:03:48 2006
New Revision: 111844
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111844
Log:
PR libgcj/24183:
* native/jni/xmlj/Makefile.in:
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-08 15:05 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 15:11 ---
This turns out to be a dup of bug 25251 which was fixed for sure for 4.1.0.
*** This bug has been marked as a duplicate of 25251 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-08 15:11
---
*** Bug 20477 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-08 15:12 ---
Fixed for 4.1.0 for sure so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-08 15:13 ---
Any news on the testcase?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Last reconfirmed|2005-11-15 20:22:08 |2006-03-08 15:16:1
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25440
--- Comment #5 from charlet at gcc dot gnu dot org 2006-03-08 15:16 ---
Nothing particularly critical in this PR, we've got plenty of other more
worrisome failures to look at.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 15:17 ---
Is there a testcase other than just compile and run nbench with
-ftree-loop-linear?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.0.3
http://gcc
--- Comment #4 from emilp at mac dot com 2006-03-08 15:23 ---
I did come on a bit strong, didn't I? Sorry about that, I'm just a bit
frustrated since it used to work better in the gcc 3 series :-)
Do you have a suggestion as to where I could continue this discussion?
--
http://gcc
--- Comment #5 from bangerth at dealii dot org 2006-03-08 15:26 ---
(In reply to comment #4)
> I did come on a bit strong, didn't I? Sorry about that, I'm just a bit
> frustrated since it used to work better in the gcc 3 series :-)
Oh, don't worry. I put a smiley to my remark, just in
--- Comment #8 from charlet at gcc dot gnu dot org 2006-03-08 15:27 ---
Given that 4.1.0 has been released and issue is fixed there, closing this
PR.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from mikpe at csd dot uu dot se 2006-03-08 15:51 ---
I downloaded and installed cctools-590.12, and that did indeed solve the
gcc-4.1.0 bootstrap problem.
However, today I discovered that the newer cctools break gcc-3.4.x.
A zero-sized global variable, e.g. "struct { } un
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 15:52 ---
People have bootstraped and tested on AIX 5.3 without any troubles before and
after this patch has been filed?
What command are you using to bootstrap GCC?
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 15:57 ---
(In reply to comment #2)
> However, today I discovered that the newer cctools break gcc-3.4.x.
> A zero-sized global variable, e.g. "struct { } unused;", gets translated
> into a ".comm _unused,1" by gcc-4, but gcc-3
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25815
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.1.1
http://gcc
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 16:06 ---
Fixed in 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|
--- Comment #10 from pcarlini at suse dot de 2006-03-08 16:08 ---
Hardly a regression, considering that ext/pb_assoc has been released for the
first time in 4.1.0 ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
--
--- Comment #5 from bonzini at gnu dot org 2006-03-08 16:11 ---
patch committed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from bonzini at gnu dot org 2006-03-08 16:10 ---
Subject: Bug 26500
Author: bonzini
Date: Wed Mar 8 16:10:44 2006
New Revision: 111845
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111845
Log:
2006-03-08 Paolo Bonzini <[EMAIL PROTECTED]>
PR bootstrap/
--- Comment #9 from pcarlini at suse dot de 2006-03-08 16:20 ---
The below also works already (can make for an useful if ugly workaround, in
some cases, e.g., c++/21682):
namespace one
{
template
void
fun(T);
}
namespace two
{
template
void
fun(T);
}
using one::fun
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-08 16:25 ---
All < 3.4.0 accept the code. Fixed with the new C++ parser.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-08 16:30 ---
Isn't this fixed in 4.1?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from allali at univ-mlv dot fr 2006-03-08 16:30 ---
(In reply to comment #2)
> All < 3.4.0 accept the code. Fixed with the new C++ parser.
>
I've checked and you're right. Is there a way to have array elements
initialized by a specific constructor in g++ > 3.4 (to get
--
gbenson at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gbenson at redhat dot com
|dot org |
--- Comment #3 from gbenson at redhat dot com 2006-03-08 16:32 ---
See http://people.redhat.com/gbenson/throwpoint-report.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21891
--- Comment #16 from law at redhat dot com 2006-03-08 16:43 ---
C++ version of the problems in 26344. Fixing 26344 will fix this bug as well.
*** This bug has been marked as a duplicate of 26344 ***
--
law at redhat dot com changed:
What|Removed
--- Comment #12 from law at redhat dot com 2006-03-08 16:43 ---
*** Bug 26406 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
--- Comment #6 from emilp at mac dot com 2006-03-08 16:47 ---
I'm considering filing a defect report (for a standard clarification) to the
commitee but I would like to make sure I'm not climbing any trees here... In
your first reply you said "My understanding is that this code is in fact
--- Comment #7 from bangerth at dealii dot org 2006-03-08 17:21 ---
(In reply to comment #6)
> I'm considering filing a defect report (for a standard clarification) to the
> commitee but I would like to make sure I'm not climbing any trees here... In
> your first reply you said "My under
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2006-03-08 17:53
---
Created an attachment (id=10992)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10992&action=view)
Reduced C testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2006-03-08 17:55
---
This is a middle-end problem:
~/eric> gcc t.c
t.c: In function 'foo':
t.c:5: warning: empty range specified
t.c:3: internal compiler error: in tree_low_cst, at tree.c:4423
Please submit a full bug report,
with p
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-08 17:56
---
Hmm, if I change the reduced testcase from 0 ... -1 to -1 ... 0, it works for
the C testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-03-08 18:10
---
Created an attachment (id=10993)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10993&action=view)
Naive fix.
It tweaks 4 (really 3) C source files and is sufficient to overcome the
problem.
But it's probab
--- Comment #11 from hp at gcc dot gnu dot org 2006-03-08 18:35 ---
Uh, make no mistake, this *is* a regression; see the original description.
There's a revision before which this test worked and a revision after
which it does not work. This happened in 4.1 era, so it's a 4.1 regression
--- Comment #3 from mckinlay at redhat dot com 2006-03-08 18:36 ---
Yes. This is fixed in GCC 4.1.
--
mckinlay at redhat dot com changed:
What|Removed |Added
--- Comment #12 from pcarlini at suse dot de 2006-03-08 18:45 ---
(In reply to comment #11)
> I changed the PR component to a historically more probable one, to avoid
> blaming libstdc++, as it seems that's an conclusion you're trying to avoid.
Agreed, *as a miscompilation*, can be a re
>
/local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/xgcc
-B/local/gnu_toolchain/build_area/obj_gcc_gcc-trunk_e500v1/./gcc/
-B/local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-linux-gnuspe/bin/
-B/local/gnu_toolchain/install-gcc-trunk-20060308-e500v1/powerpc-unknown-li
Testcase:
int *d1;
int g(int *b)
{
d1 = b;
}
int f(int a, int b, int c)
{
int i, j;
int *d;
if (a)
d = &i;
else
d = &j;
i = 2;
j = 3;
g(&b);
if (i!=2)
link_error();
if (j!=3)
link_error();
return *d;
}
int main(void)
{
f(1, 2,3);
return 0;
}
This should link
--- Comment #1 from edmar at freescale dot com 2006-03-08 19:01 ---
Created an attachment (id=10994)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10994&action=view)
Intermediate file for reported bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC host triplet|x86_64-unknown-linux-gnu|
Summary|Illegal inlined assembler on|[4.2 Regression] Ill
--- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 ---
I can reproduce the runtime error, but not the compile error.
pantani:/tmp/2$ type gcc
gcc is /tmp/2/bin/gcc
pantani:/tmp/2$ gcc a.c -fopenmp
pantani:/tmp/2$ ./a.out
./a.out: error while loading shared libraries: libg
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 19:07 ---
Subject: Re: Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
>
>
>
> --- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 ---
> I can reproduce the runtime error, but not
>
>
>
> --- Comment #1 from aldyh at gcc dot gnu dot org 2006-03-08 19:05 ---
> I can reproduce the runtime error, but not the compile error.
>
> pantani:/tmp/2$ type gcc
> gcc is /tmp/2/bin/gcc
> pantani:/tmp/2$ gcc a.c -fopenmp
> pantani:/tmp/2$ ./a.out
> ./a.out: error while loading
--- Comment #2 from edmar at freescale dot com 2006-03-08 19:10 ---
Same error observed on gcc-4_1-branch 20060308
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26607
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
Summary|[4.2 Regression] Illegal|[4.1/4.2 Regr
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 19:11 ---
This was caused by the 128bit long doubles patches (well really caused by a
secondary patch to work around a code gen issue).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from tromey at gcc dot gnu dot org 2006-03-08 19:27 ---
I've been looking into this a bit.
The current problem I see is that the heavyweight lock stuff
relies on the GC. This won't interact well with the current
code in natReference.cc, as those data structures are not
--- Comment #8 from igodard at pacbell dot net 2006-03-08 19:29 ---
Well I was really surprised to see this -fpreprocessed option in the -v output,
so I did a little digging. It seems that this option is set by the driver
whenever -save-temps is set. It does not come from my command line
Testcase:
int h(int *);
struct a1
{
int i[2];
};
void link_error();
int f(struct a1 a, int i,int *c)
{
int b;
void *g = &a.i[i];
*(int*)g = 1;
h(&b);
if (a.i[i] !=1)
link_error();
return b+c[i*2];
}
---
# VUSE ;
# VUSE ;
# VUSE ;
D.1996_14 = *D.1995_13;
That i
On Wed, 2006-03-08 at 18:59 +, pinskia at gcc dot gnu dot org wrote:
> Testcase:
> int *d1;
> int g(int *b)
> {
> d1 = b;
> }
> int f(int a, int b, int c)
> {
> int i, j;
> int *d;
> if (a)
> d = &i;
> else
> d = &j;
> i = 2;
> j = 3;
> g(&b);
> if (i!=2)
>link_err
--- Comment #1 from dberlin at gcc dot gnu dot org 2006-03-08 19:44 ---
Subject: Re: New: address of local variables
are said to escape even though it is obvious they don't
On Wed, 2006-03-08 at 18:59 +, pinskia at gcc dot gnu dot org wrote:
> Testcase:
> int *d1;
> int g(
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 19:44 ---
Also this bug which is most likely what is causing there to be too many VOPS in
the current representation which is why I added memory-hog and compile-time-hog
to the keywords.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 19:47 ---
Variable: i, UID 1520, int, is aliased, is addressable, default def: i_3
Variable: j, UID 1521, int, is aliased, is addressable, default def: j_5
Variable: b, UID 1516, int, is aliased, is addressable, call clobber
--- Comment #1 from langel at redhat dot com 2006-03-08 20:51 ---
Created an attachment (id=10995)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10995&action=view)
roll mouse over text area and choice box
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22163
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 21:24 ---
Hmm, looking at this again, it looks really like PR 23086.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pault at gcc dot gnu dot org 2006-03-08 21:44 ---
I have a patch which is just now regtesting. It does the obvious:
set initial index = 0
if (the max/min condition is met or index = 0)
{
set index to the current position
update the value for comparison
mminimal-toc raid6int8.i
Reading specs from
/home/bergner/install-3_4/lib/gcc/powerpc64-linux/3.4.6/specs
Configured with: /home/bergner/gcc-20060308-3_4/configure
--target=powerpc64-linux --host=powerpc64-linux --build=powerpc64-linux
--with-cpu=default32 --enable-threads=posix --enable-shared
--- Comment #1 from bergner at vnet dot ibm dot com 2006-03-08 22:03
---
Created an attachment (id=10997)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10997&action=view)
Reduced test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26610
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 22:07 ---
3.4.6 is frozen and 3.4.x is now retired.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from langel at redhat dot com 2006-03-08 22:18 ---
Created an attachment (id=10998)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10998&action=view)
problem is caused because of the drawImage call in paint. updated test case
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 22:21 ---
I should had looked into this one. This is what I was afraid of when this
idea 128bits long double went it. It was not the optimization which I thought
was applied but instead just the compiling of darwin-ldouble.
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-03-08 22:28
---
I think the code in Comment #1 is unambiguously invalid.
7.3.3/11 says says that a function declaration in namespace scope may not match
the declaration of a function introduced by a using declaration; i.e., the
I consistently get the following ICE on this C++ code.
omp_harness.cpp:39: internal compiler error: in omp_add_variable, at
gimplify.c:4257
The code is not legit and there are several errors but this is because I have
cut down a larger program.
I am using the gomp-branch and gcc -v reports:
Usi
--- Comment #1 from bowie dot owens at csiro dot au 2006-03-08 22:34
---
Created an attachment (id=10999)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10999&action=view)
preprocessed output from save-temps that triggers ICE
GZIP compressed to make it within the size limit. Will
1 - 100 of 135 matches
Mail list logo
