Jerry DeLisle wrote:
Paul Thomas wrote:
Andrew,
and the testcase here.
¿Que?
Paul
See attachment in PR26001
LAPACK tests run OK with the patch. Thanks to Dominique Dhumieres for initial
reduced case and Andrew Pinski for squeezing this in. Hope we can get it
committed to 4.1 and tr
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2006-01-31 06:39
---
I ran the full LAPACK test suite and it successfully passes with the patch in
comment #17. Results are pretty good/typical for -O3.
$ grep fail *.out
cgd.out: CGV drivers: 67 out of 1092 tests failed to p
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-31 05:33
---
Note if PR 22303 was fixed, then the code in expr.c could be removed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
--- Comment #17 from pinskia at gcc dot gnu dot org 2006-01-31 05:19
---
Created an attachment (id=10765)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10765&action=view)
Patch which still needs to bootstrap/tested but it works on my simple example
ChangeLog:
* expr.c (expand_exp
--- Comment #2 from hjl at lucon dot org 2006-01-31 04:58 ---
How about this?
[EMAIL PROTECTED] cpu2006-465b]$ !cat
cat foo.f90
module foo
publicbar_
interface bar_
module procedure bar
end interface
publicxxx_
interface xxx_
module procedure xxx
en
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-31 04:56
---
The bug is around expr.c:7128.
Working on this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 04:05 ---
*** This bug has been marked as a duplicate of 23614 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-31 04:05 ---
*** Bug 26044 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-31 04:05 ---
*** Bug 26043 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 04:05 ---
*** This bug has been marked as a duplicate of 23613 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Executing on host: /home/dave/gnu/gcc-4.1/objdir/gcc/testsuite/../g++
-B/home/da
ve/gnu/gcc-4.1/objdir/gcc/testsuite/../
/home/dave/gnu/gcc-4.1/gcc/gcc/testsuite
/obj-c++.dg/lookup-2.mm -nostdinc++
-I/home/dave/gnu/gcc-4.1/objdir/hppa-linux/
libstdc++-v3/include/hppa-linux
-I/home/dave/gnu/gcc-4.1
Executing on host: /home/dave/gnu/gcc-4.1/objdir/gcc/testsuite/../g++
-B/home/da
ve/gnu/gcc-4.1/objdir/gcc/testsuite/../
/home/dave/gnu/gcc-4.1/gcc/gcc/testsuite
/obj-c++.dg/isa-field-1.mm -nostdinc++
-I/home/dave/gnu/gcc-4.1/objdir/hppa-lin
ux/libstdc++-v3/include/hppa-linux
-I/home/dave/gnu/gcc-
--- Comment #7 from wilson at gcc dot gnu dot org 2006-01-31 03:49 ---
Things start going wrong in the reload inheritance code. For reload 0, for
insn 11, we choose to inherit the value already in r14 in an inner loop in
choose_reload_regs. Near the end, we double check to make sure we
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 03:16 ---
Confirmed on powerpc-darwin also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
This source file, when compiled with gcj produces an ICE:
package x;
class One
{
long l;// no ICE if this is int, not long
int b; // no ICE if this line is gone; type doesn't matter
}
class Two
{
class Three extends One { }
Three three () { return new Three (); }
}
The a
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-31 02:44
---
This is a relatively low priority regression; we get valid errors before the
crash.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 02:04 ---
This does not look like valid code.
As the types of the dummy z are different.
The error message is bogus but that is a different bug. PR 20067.
Arrays have nothing to do with it by the way, you can reproduce the er
--- Comment #7 from hjl at lucon dot org 2006-01-31 01:52 ---
The original code looks like
subroutine foo(self)
character(*) :: self
pointer :: self
nullify(self)
allocate(self)
self = " "
end subroutine
Is this code valid? How can I make it valid?
-
[EMAIL PROTECTED] cpu2006-465]$ cat foo.f90
module foo
publicbar_
interface bar_
module procedure bar
end interface
publicxxx_
interface xxx_
module procedure xxx
end interface
contains
subroutine xxx(self,z)
interface
function self(z) result(
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-01-31 01:21
---
More comments about this issue can be found in the following libstdc++ thread:
http://gcc.gnu.org/ml/libstdc++/2006-01/msg00177.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9925
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-01-31 01:20
---
*** Bug 26040 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-31 01:20 ---
*** This bug has been marked as a duplicate of 9925 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
I'm having trouble understanding what's going on here. Is this a bug in G++ or
possible is the C++ standard a little bit funny, or is it STL?
Perhaps, the result of this code undefined due to the temporary?
I would have expected as output
Hello
Hello
The rationale for this example is the follo
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-31 01:15 ---
Subject: Re: FORTRAN segfault
On Jan 30, 2006, at 7:45 PM, hjl at lucon dot org wrote:
> Intel FORTRAN compiler has no problem with it.
Intel's Fortran compiler does not detect a lot of
invalid code, that does no
On Jan 30, 2006, at 7:45 PM, hjl at lucon dot org wrote:
Intel FORTRAN compiler has no problem with it.
Intel's Fortran compiler does not detect a lot of
invalid code, that does not make this code valid.
-- Pinski
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26018
--- Comment #13 from uweigand at gcc dot gnu dot org 2006-01-31 01:11
---
Fixed in mainline and 4.1.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-31 01:11
---
The other time pi->pt_global_mem is set to 1 is when vi->is_artificial_var and
vi->is_heap_var is set.
now trying to turn off is_artificial_var and what David pointed out does not
work, because we don't have a way
--- Comment #12 from uweigand at gcc dot gnu dot org 2006-01-31 01:09
---
Subject: Bug 26018
Author: uweigand
Date: Tue Jan 31 01:09:36 2006
New Revision: 110423
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110423
Log:
PR target/26018
* config/s390/s390.c (str
--- Comment #11 from uweigand at gcc dot gnu dot org 2006-01-31 01:06
---
Subject: Bug 26018
Author: uweigand
Date: Tue Jan 31 01:06:16 2006
New Revision: 110422
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110422
Log:
PR target/26018
* config/s390/s390.c (str
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-31
01:04 ---
Subject: Re: [4.2 Regression] gcc.c:3866: warning: comparison between signed
and unsigned
> These show up when MODIFY_TARGET_NAME is defined.
This is a macro that I hadn't noticed before. It seems the PA
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-31 00:59 ---
Subject: Re: FORTRAN segfault
>
>
>
> --- Comment #4 from hjl at lucon dot org 2006-01-31 00:45 ---
> This code is extracted from a much larger program. Intel FORTRAN compiler
> has no problem with it.
>
>
>
> --- Comment #4 from hjl at lucon dot org 2006-01-31 00:45 ---
> This code is extracted from a much larger program. Intel FORTRAN compiler
> has no problem with it.
And what should it allocate a zero sized string?
-- Pinski
--- Comment #14 from dje at gcc dot gnu dot org 2006-01-31 00:49 ---
The parameter is considered global because it is marked DECL_EXTERNAL. And it
is marked EXTERNAL in tree-ssa-structalias.c:
heapvar = create_tmp_var_raw (TREE_TYPE (TREE_TYPE (t)), PARM_NOALIAS");
DECL_EXTERNA
--- Comment #4 from hjl at lucon dot org 2006-01-31 00:45 ---
This code is extracted from a much larger program. Intel FORTRAN compiler
has no problem with it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26038
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-31 00:06 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 23:59 ---
If I change the program to use a constant size string, it works.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-30 23:48 ---
This code is meaning less as far as I can tell but it is accepted by Lahey's
compilers.
Oh don't try redhat's branch please it is not something that is just wrong to
do with a modifed compiler at least in bug report
--- Comment #11 from wilson at tuliptree dot org 2006-01-30 23:24 ---
Subject: Re: problems with -Wformat and bit-fields
On Mon, 2006-01-23 at 16:06, tony dot luck at intel dot com wrote:
> u64 den : 32, num : 32; /* numerator & denominator */
> printf("den=%lx num=%lx\
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-01-30 23:16 ---
Created an attachment (id=10764)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10764&action=view)
patch
Same problem (lack of check) with min/maxloc, product and sum, although
with different results.
--
tk
I'm onto this.
$ cat maxval.f90
program main
integer, dimension(2) :: a
logical, dimension(2,1) :: lo
a = (/ 1, 2 /)
lo = .true.
print *,maxval(a,mask=lo)
end program main
$ gfortran maxval.f90
maxval.f90: In function 'MAIN__':
maxval.f90:5: internal compiler error: Segmentation fault
Pl
--- Comment #1 from hjl at lucon dot org 2006-01-30 22:39 ---
It happens on gcc 4.2, 4.1 and 4.0. But gcc-4.1-redhat is fine:
[EMAIL PROTECTED] cpu2006]$ /usr/gcc-4.1-redhat/bin/gcc -S foo.f90 -O2
[EMAIL PROTECTED] cpu2006]$ /usr/gcc-4.1-redhat/bin/gcc --version
gcc (GCC) 4.1.0 20060128
[EMAIL PROTECTED] cpu2006]$ cat foo.f90
subroutine foo(self)
character(*) :: self
pointer :: self
allocate(self)
end subroutine
[EMAIL PROTECTED] cpu2006]$ /usr/gcc-4.2/bin/gcc -S foo.f90 -m32
foo.f90: In function foo:
foo.f90:4: internal compiler error: Segmentation fault
P
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 22:29 ---
(In reply to comment #2)
> I CAN COMPILE binutils-2.16.1 successfully, but why can't I use them?
Because it has not been ported to AIX 5 yet.
> What is if i need to compile apps, which need binutils ?
Ask the app n
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-30 22:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from eedelman at gcc dot gnu dot org 2006-01-30 22:24
---
Subject: Bug 24266
Author: eedelman
Date: Mon Jan 30 22:23:57 2006
New Revision: 110412
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110412
Log:
fortran/
2005-01-30 Erik Edelmann <[EMAIL PROTECTED]>
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-30 22:11 ---
Ok, I have now tried a 3.4.x and also a 3.3.x. and found some interesting
results.
Well it is a regression only in 3.4.1 and above and 3.3.5 and above.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #7 from hp at gcc dot gnu dot org 2006-01-30 21:53 ---
Re: "needing two rounds". Looks like you're hung up on my choice of words.
I suggest ignore that and instead just run the test-case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25335
--- Comment #4 from brainchild at skyler dot com 2006-01-30 21:42 ---
Sorry, just realized that's not what you asked for. Here is output of gcc -v:
$ ./gcc -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --pr
--- Comment #3 from brainchild at skyler dot com 2006-01-30 21:40 ---
Per your request, the --version output:
g++ (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. Th
--- Comment #2 from brainchild at skyler dot com 2006-01-30 21:36 ---
The gcc version is 3.4.4, the one in the current Cygwin distribution.
It must have been fixed since then, though. I downloaded and built gcc 4.0.2
and it gives the correct output, i_=1. So, I guess you can consider
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26029
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-01-30 20:24 ---
> Reload seems to need two rounds, but the emitted reload insns for each pass
> is left around. This is exposed but not actually caused by the fix for
> PR middle-end/24912.
Reload should be only called once per fun
--- Comment #14 from tobi at gcc dot gnu dot org 2006-01-30 19:37 ---
(In reply to comment #13)
> (In reply to comment #12)
> > > this (t02.original) looks like a possible off-by-one error.
> >
> > [1] here is correct, the arrary bounds is 1:1 and not the C array bounds
> > starting at
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-30 19:39
---
(In reply to comment #14)
> Sounds like the tree-optimizers should have replaced "0"[1] with '0'. This
> also sounds like it was pure chance that the bug didn't trigger at -O0.
Yes they should have but that is a
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-01-30 19:32
---
(In reply to comment #12)
> > this (t02.original) looks like a possible off-by-one error.
>
> [1] here is correct, the arrary bounds is 1:1 and not the C array bounds
> starting at 0.
I should mention the off by
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-01-30 19:27
---
(In reply to comment #11)
> I'm not sure what you're trying to say, so let me rephrase: given the advanced
> state of 4.1 in the relase cycle, it may make sense to revert Feng Wang's
> patch
> in 4.1, and to fix t
--- Comment #11 from tobi at gcc dot gnu dot org 2006-01-30 19:23 ---
(In reply to comment #10)
> (In reply to comment #8)
> > Did the regression also happen on 4.1? We should probably revert Feng
> > Wang's
> > patch there.
>
> But there is a latent bug. I don't know a way to reprod
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-30 19:13
---
(In reply to comment #8)
> Did the regression also happen on 4.1? We should probably revert Feng Wang's
> patch there.
But there is a latent bug. I don't know a way to reproduce this without Feng's
patch in C or
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-01-30 19:08 ---
Actually it is not complete unrolling that is going wrong but expand.
static char intstr[1:10] = "0123456789";
;; if (c1$1 == intstr[1]{lb: 1 sz: 1}) (void) 0; else goto ;
(insn 85 83 86 (set (reg:CCZ 17 flags)
--- Comment #8 from tobi at gcc dot gnu dot org 2006-01-30 19:07 ---
Did the regression also happen on 4.1? We should probably revert Feng Wang's
patch there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-01-30 19:02 ---
Complete unrolling is causing it but I have not looked why.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-30 18:59 ---
It was the patch which changed string(c:c) == string1(c:c) to be inlined but it
is a latent bug from looking at the tree dumps.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
eedelman at gcc dot gnu dot org changed:
What|Removed |Added
CC||eedelman at gcc dot gnu dot
|
--- Comment #5 from tobi at gcc dot gnu dot org 2006-01-30 18:51 ---
There were not many changes to the tree during that time. I think the only
possible culprit is Feng Wang's patch for length-one characters.
--
tobi at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-30 18:49 ---
I have a feeling it is one of the string patches that went in around the 8th.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from kargl at gcc dot gnu dot org 2006-01-30 18:42 ---
For a reduced testscase see
http://gcc.gnu.org/ml/fortran/2006-01/msg00407.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26001
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-01-30 18:38 ---
(In reply to comment #2)
> Strange - both on mainline and the 4.1 branch, I can reproduce this (albeit
> with
> a more sensible variable name of "u") for i686-pc-linux-gnu native, but not
> for
> a cross to sh-elf.
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-30 18:38
---
(In reply to comment #9)
> The problem is the construct &&label1 - &&label2 used in the
> source (b.t.w. is this usage of the GCC &&label extension
> valid in the first place?
It is "correct" but not does could me
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-01-30 18:32
---
This appears to be a pre-existing bug in s390_decompose_address,
that happens to be triggered by this particular glibc code.
The problem is the construct &&label1 - &&label2 used in the
source (b.t.w. is this usag
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-01-30 18:31 ---
> It appears we actually don't have any way to query from the
> frontend-indenpendent code if we can mark something as
> safely.
^ addressable
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26004
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-01-30 18:29 ---
(In reply to comment #3)
> This is caused by the following code in gimplifier:
> 3297if (use_target)
> 3298 {
> 3299CALL_EXPR_RETURN_SLOT_OPT (*from_p) = 1;
> 3300
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-30 18:17
---
*** Bug 21924 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 18:17 ---
Mark as a dup of bug 7049.
*** This bug has been marked as a duplicate of 7049 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-30 18:17 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #4 from gdr at integrable-solutions dot net 2006-01-30 18:14
---
Subject: Re: no match for 'operator<<'
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| I should note this is called argument dependent lookup (or ADL, there is
| another name for it after a pe
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-30 18:07 ---
I don't get a hang but I do get an ICE after some errors.
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-01-30 18:05
---
Fixed for 4.1.0 and 4.2.0 at least.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-30 18:04 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 18:03 ---
I should note this is called argument dependent lookup (or ADL, there is
another name for it after a person but he no longer wants to be associated with
this).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2603
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-30 18:01 ---
This is caused by the following code in gimplifier:
3297if (use_target)
3298 {
3299CALL_EXPR_RETURN_SLOT_OPT (*from_p) = 1;
3300lang_hooks.mark
--- Comment #9 from pcarlini at suse dot de 2006-01-30 18:01 ---
... invalid.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|REOPENED
--- Comment #8 from pcarlini at suse dot de 2006-01-30 18:00 ---
Reopen to adjust to...
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|RESOLVE
--- Comment #2 from pcarlini at suse dot de 2006-01-30 18:00 ---
Not a bug, this is how name lookup works. And any conforming, up to date,
compiler behaves in the same way. You can fix your code moving operator<<
inside namespace MyNameSpace.
I'm sure there are many duplicates, I'm goin
--- Comment #7 from pcarlini at suse dot de 2006-01-30 18:00 ---
*** Bug 26037 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
-
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-01-30 17:42 ---
Strange - both on mainline and the 4.1 branch, I can reproduce this (albeit
with
a more sensible variable name of "u") for i686-pc-linux-gnu native, but not for
a cross to sh-elf. Yet the failing mark_addressable ca
--- Comment #1 from ben at pc-doctor dot com 2006-01-30 17:41 ---
(In reply to comment #0)
> Please note that "i" is also undeclared.
Err, i is not a variable so ignore that statement. I am assuming gcc is
treating the "WrapperClass wrapper0(TestClass(i));" as a declaration instea
--- Comment #1 from tony dot luu at baesystems dot com 2006-01-30 17:31
---
Created an attachment (id=10763)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10763&action=view)
test code
fail to compile with g++ 3.4.5.
compiles ok with other compilers (SGI, SUN).
--
http://gcc.
The following stripped-down code fails to compile in g++3.4.5 (compiles fine
with other compilers).
// CODE SNIPPET.
#include
#include
#include
#include
namespace MyNameSpace {
struct Point
{
double x;
double y;
double z;
};
} // namespace
std::ostream&
operator<<
--- Comment #23 from amylaar at gcc dot gnu dot org 2006-01-30 17:22
---
Fixed on mainline and the 4.1 branch.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from sje at gcc dot gnu dot org 2006-01-30 17:06 ---
Subject: Bug 25318
Author: sje
Date: Mon Jan 30 17:06:16 2006
New Revision: 110405
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110405
Log:
PR testsuite/25318
* lib/target-supports.exp (check_e
--- Comment #4 from sje at gcc dot gnu dot org 2006-01-30 17:08 ---
Subject: Bug 25318
Author: sje
Date: Mon Jan 30 17:08:10 2006
New Revision: 110406
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110406
Log:
PR testsuite/25318
* lib/target-supports.exp (check_e
The following code, while invalid, causes g++ >= 4.0.0 to hang while compiling.
Please note that "i" is also undeclared. GCC 3.4.4 errors out as expected.
class TestClass {
public:
int m_z;
};
class WrapperClass {
public:
TestClass m_test;
};
int main()
{
WrapperClass wrapp
--- Comment #4 from tromey at gcc dot gnu dot org 2006-01-30 16:37 ---
You may want to send the GC patch upstream, to the GC list.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from aph at gcc dot gnu dot org 2006-01-30 16:25 ---
Subject: Bug 21428
Author: aph
Date: Mon Jan 30 16:25:40 2006
New Revision: 110402
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110402
Log:
2006-01-30 Andrew Haley <[EMAIL PROTECTED]>
PR java/21428
--- Comment #22 from amylaar at gcc dot gnu dot org 2006-01-30 16:19
---
Subject: Bug 14798
Author: amylaar
Date: Mon Jan 30 16:19:11 2006
New Revision: 110401
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110401
Log:
PR target/14798:
gcc:
* sh.c (pragma_interr
--- Comment #9 from aph at gcc dot gnu dot org 2006-01-30 15:40 ---
Subject: Bug 21428
Author: aph
Date: Mon Jan 30 15:40:14 2006
New Revision: 110400
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110400
Log:
2006-01-30 Andrew Haley <[EMAIL PROTECTED]>
PR java/21428
--- Comment #21 from amylaar at gcc dot gnu dot org 2006-01-30 15:07
---
Subject: Bug 14798
Author: amylaar
Date: Mon Jan 30 15:07:43 2006
New Revision: 110398
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110398
Log:
PR target/14798:
gcc:
* sh.c (pragma_interrupt, tr
--- Comment #7 from alex at milivojevic dot org 2006-01-30 14:50 ---
(In reply to comment #5)
> ld from binutils 2.16.1 does not resolve this issue.
> GNU assembler version 2.16.1 (sparc-sun-solaris2.10) using BFD version 2.16.1
> sparc-sun-solaris2.10
I used recent weekly snapshot of b
1 - 100 of 139 matches
Mail list logo
