I'm not dependent on it, although at some point, I'm sure i may take a
closer look at the code to see how they've done certain things.
Just as a reminder, even though the Microchip code is covered by the GPL,
code based on it won't be acceptable for inclusion into FSF GCC unless
you can get
I'm not quite sure I follow you.. if its possible to dedicate a register to
act as the data-stack pointer, and implement it that way, why would I want
to keep the SP as a virtual register? I'm not being antagonistic when I
say that.. I'm just trying to understand what you're trying to tell
On 11 April 2006 08:47, Colm O' Flaherty wrote:
I'm not quite sure I follow you.. if its possible to dedicate a register to
act as the data-stack pointer, and implement it that way, why would I want
to keep the SP as a virtual register?
Because then you would /not/ have to sacrifice one
On 11 April 2006 02:34, Mark Cuss wrote:
Hello
I've subscribed to the gcc mailing list from my work account
([EMAIL PROTECTED]) but none of my posts appear on the mailing
list...
Ok. point one:
The mail doesn't get bounced back so I assume it's getting
delivered,
That's a
Florian Weimer wrote:
* Mark Mitchell:
1. What do we do if people do advertise jobs that are not free software
jobs, or not purely free software jobs? How pure is pure? Does Port
GCC to proprietary OS count as free or not?
And: Does porting GCC to a new processor, to run on a free
Hello,
Dear mailing list,
is there something wrong with the following code?
--
basic_block my_basic_block;
basic_block dup_basic_block;
FOR_EACH_BB(my_basic_block)
{
dup_basic_block = duplicate_block(bb, NULL);
}
I assume you mean
dup_basic_block =
On Apr 11, 2006, at 03:46, Colm O' Flaherty wrote:
I'm not quite sure I follow you.. if its possible to dedicate a
register to act as the data-stack pointer, and implement it that
way, why would I want to keep the SP as a virtual register? I'm
not being antagonistic when I say that.. I'm
Mark Mitchell [EMAIL PROTECTED] writes:
| Mike Stump wrote:
|
| 3. How do we enforce any of these rules?
|
| Shame on those that violate them.
|
| I think we need to do better than that.
I'll vote for keeping the current policy: not job ads on the
development list.
-- Gaby
Thanks,
Can you give me a hint of the three following fields? Some passes defined
them (such as pass_lower_cf), but soem passes leave them as NULL/0.
Thanks,
37 struct tree_opt_pass
38 {
63 /* Sets of properties input and output from this pass. */
64 unsigned int
Gerald Pfeifer wrote:
Personally, I'd be in favor of GCC-releated internships and job offers on
our lists, but I see that it may be difficult to draw a line. That said,
I wonder how to handle .signatures: for example, if you added a line like
CodeSourcery is hiring. http://.../work4us/;,
Hello
I'm trying to build gcc 3.4.4 on a sparc machine running Solaris 9. My
build setup was:
../gcc-3.4.4/configure --diabled-shared --prefix=install
dir --enable-languages=c,c++
make bootstrap
(the install dir is the same directory which I previously compiled and
installed binutils
I'm trying to build gcc 3.4.4 on a sparc machine running Solaris 9. My
build setup was:
../gcc-3.4.4/configure --diabled-shared --prefix=install
dir --enable-languages=c,c++
make bootstrap
I see 4 potential problems:
- do not use a relative path to configure,
- --diabled-shared is probably
Thanks Eric
I thought it was OK to use a relative path. From what I understood, it is a
bad idea to build inside the directory that the gcc tar file is uncompressed
into, but I guess I can specifiy the path in full.
Definitely a typo in the email on the disable shared thing
I'm using GNU
I thought it was OK to use a relative path. From what I understood, it is
a bad idea to build inside the directory that the gcc tar file is
uncompressed into, but I guess I can specifiy the path in full.
Yes, and while you are at it, use the recommended config shell.
--
Eric Botcazou
I try compile example program
gcc.exe -Ic:\gcc\include -Lc:\gcc\lib c:\gcc\bin\program.c
gcc.exe: Internal error: (null) (program as)
Please submit bug report.
Free is bad?
_
Express yourself instantly with MSN Messenger! Download
Yes, I meant
--
basic_block my_basic_block;
basic_block dup_basic_block;
FOR_EACH_BB(my_basic_block)
{
dup_basic_block = duplicate_block(my_basic_block, NULL);
}
--
I also got some more precise context. The statement being copied at
that point is:
--
*D.1600 = 0;
--
whose GIMPLE
I send a message to John Elliott's listed address yesterday, and I have
not yet received an immediate response. I will post to this list if I
receive anything from him.
So, I'd caution anyone away from basing any work on the dsPIC port until
some specific understanding is established with
Ok - it built this time. I guess I should read the instructions - my
fault...
Thanks for the help!
Mark
- Original Message -
From: Eric Botcazou [EMAIL PROTECTED]
To: Mark Cuss [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org
Sent: Tuesday, April 11, 2006 10:52 AM
Subject: Re: gcc 3.4.4 build
On Apr 10, 2006, at 4:30 PM, Mark Mitchell wrote:
It seems like we're getting consensus around that approach, despite
the
initial sentiment in the other direction from Mike and Joe.
Mike, Joe, do either of you care to argue the point?
I'm fine with the status quo. I think comp.compilers
Thanks Sandro, I have checked this in to the trunk and the 4.1 branch.
It would be great to get a copyright assignment form from you so that we
can check in the rest of your Darwin/x86 patches. Have you started the
copyright assignment process? If not, the form to do so can be found here:
Roger Sayle wrote:
such a step. Is such a transition safe for stage 3 mainline,
and/or would front-ends prefer some time to double check that
this won't cause problems on conformance tests not part of GCC's
testsuite.
I think it's reasonable to make this change at this point, as there are
Hi,
First I apologize, if this is the wrong list. :)
I hope someone from the developer's group can't point me in the right
direction? I did not get a response on GCC-help list.
I am trying to compile code that uses the
vector processor (SPE) found on the E500 (i.e. MPC8540)
I am using the SPE
hi,
You know that treelang prescribes the function prototype must give the
storage class type explicitly, for an example, external_definition
int add(int arg1, int arg2);
I'd like to know how to modify the parse.y to let the storage type can
be implicitly and the default type is
On Monday 10 April 2006 19:48, you wrote:
Can it at least add (small) immediates to registers?
Nope, sry. The only instructions that take other arguments than registers are
the aforementioned LDL/LDH (load low/high), branch instructions (they take a
memory address) and four bit operations
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2006-04-11 06:06
---
Sorry, the patch doesn't seem to help at all.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from amodra at bigpond dot net dot au 2006-04-11 06:09
---
Current 4.0, 4.1, and mainline compile the testcase OK.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
The following code aligns and increments a pointer twice. I expect an offset of
8 with respect to the original address. Works as expected with an unoptimized
build, but an an offset of 4 is reported when compiled with -O2. The problem
seems to be the cast to (long) before the arithmetic operations
if /bin/sh /usr/local/bin/libtool --silent --tag=CXX
--mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I..
-I../dcop -I. -I../kio/kssl -I../kjs -I../kdefx
-I../kdecore/network -I../dcop -I../libltdl -I../kdefx
-I../kdecore -I../kdecore -I../kdeui -I../kio
-I../kio/kio -I../kio/kfile -I..
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-11 08:28 ---
Confirmed. The following aborts with -O2 and works with -O, optimized tree
dumps are identical.
extern C void abort(void);
struct Test { char *p; };
inline void align(char* p)
{
((long )p) += 3;
((long )p)
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-11
08:59 ---
Iguchi-san,
You are correct. The reference to foo with an integer argument is disambiguated
by the use of the keyword.
The only compiler that I have found that handles this correctly is DF5.0/6.0.
struct S
{
S () : d(1.0) {}
S (const double x) : d(x) {}
S (const S x) : d(x.d) {}
const S operator= (const S x) { d = x.d; return *this; }
bool operator (const S x) const { return d x.d; }
double d;
};
S
foo (S a, S b)
{
S c = ({ (a b) ? a : b; });
return c;
}
extern C void
--- Comment #1 from jakub at gcc dot gnu dot org 2006-04-11 09:01 ---
Well, the (void) *a; and (void) *b; certainly don't look ok, so the problem
is earlier. Sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27115
--- Comment #2 from falk at debian dot org 2006-04-11 09:40 ---
It seems to me that t.p, which is of type char*, is accessed via an lvalue
of type long. So this is undefined behavior. Or am I missing something?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27114
--- Comment #3 from pluto at agmk dot net 2006-04-11 10:03 ---
-O2 -fno-inline works (tested on x86-64).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27114
The following test demonstrates an incorrect sign in the following division :
#include stdio.h
int main (void)
{
volatile long int n;
n = -2;
printf (%ld\n, (-2147483647L - 1L) / (-n));
return 0;
}
I get a correct result with 4.0.3, and a wrong sign with snapshots 20060325 and
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-11 10:33 ---
Oh, right. I was confused about 'char' and didn't see the alias violating.
*** This bug has been marked as a duplicate of 21920 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #91 from rguenth at gcc dot gnu dot org 2006-04-11 10:33
---
*** Bug 27114 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The cross build for sh64-elf on x86 hosts fails during compilation
of libiberty/ramdom.c for 32bit SHmedia with
libiberty/random.c:362: internal compiler error: in push_reload, at
reload.c:1265
The following is a reduced testcase. It ICEs with -O1 -m5-32media
on sh64-elf.
extern int tbl[32];
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-04-11 10:46 ---
Overflow flag set problem:
n = -2;
n.10 = n;
D.2132 = -08000 / n.10;
-fwrapv fixes the problem. This is a dup of ...
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
laszlo dot szakony at philips dot com changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26846
I'm bootstrapping trunk on Solaris x86 after a fresh svn up and I get this:
gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
-fno-common -DHAVE_CONFIG_H -I. -I. -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc
--- Comment #1 from brett dot albertson at stratech dot com 2006-04-11
14:44 ---
nevermind. svn update error.
--
brett dot albertson at stratech dot com changed:
What|Removed |Added
--- Comment #2 from laurent at komite dot net 2006-04-11 15:06 ---
(In reply to comment #1)
Overflow flag set problem:
n = -2;
n.10 = n;
D.2132 = -08000 / n.10;
-fwrapv fixes the problem. This is a dup of ...
I'm not sure this is just an overflow problem, it might
--- Comment #3 from vincent at vinc17 dot org 2006-04-11 15:16 ---
(In reply to comment #2)
which is incorrect since the input domain is not symmetric wrt 0.
I disagree. Could you give an explicit example?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27116
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-04-11 15:25 ---
I mean the middle-end probably does some interesting foldings of -2147483647L
- 1L as the result -08000 has the overflow flag set. It doesn't do it with
-fwrapv though.
--
--- Comment #4 from avi at argo dot co dot il 2006-04-11 15:36 ---
Benchmark results, 32 bit code, various methods
On an athlon 64:
bts reg, (reg): 1 cycle
bts reg, (mem): 3 cycles
C code (reg):1 cycle
C code (mem):5 cycles
On a Xeon:
bts reg, (reg): 6
--- Comment #5 from avi at argo dot co dot il 2006-04-11 15:38 ---
Created an attachment (id=11243)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11243action=view)
benchmark for various set_bit() implementions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
--- Comment #6 from avi at argo dot co dot il 2006-04-11 15:39 ---
oops, the benchmark was for bts. will do again for bt.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25671
--- Comment #5 from vincent at vinc17 dot org 2006-04-11 15:46 ---
(In reply to comment #4)
I mean the middle-end probably does some interesting foldings of
-2147483647L
- 1L as the result -08000 has the overflow flag set.
The bug also occurs with: (long) -2147483648LL.
--
--- Comment #6 from vincent at vinc17 dot org 2006-04-11 15:50 ---
BTW, concerning the overflow flag, I think it comes from the sign cancellation:
the long constant -2147483648 is replaced its opposite, but the opposite is not
representable in a long, hence the overflow.
--
--- Comment #7 from avi at argo dot co dot il 2006-04-11 15:53 ---
Created an attachment (id=11244)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11244action=view)
bt instruction benchmark
redone the test for test_bit(), this time always forcing a memory access:
Athlon 64:
--- Comment #7 from guillaume dot melquiond at ens-lyon dot fr 2006-04-11
15:55 ---
I disagree. Could you give an explicit example?
Sorry, my mistake, I should not have suggested this testcase: this optimization
is indeed fine (yet GCC 4.1 does not apply it). The following testcase
int foo(int i)
{
char buffer[10];
return buffer[i];
}
does not warn about the use of uninitialized array buffer. While
int foo(int i)
{
char buffer[10];
return buffer[2];
}
does. Likewise for C++.
--
Summary: Should warn about uninitialized use of variable array
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-11 17:25 ---
Can you give some sources that don't use automake? Because it is hard to
follow what is wrong in this bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 17:30 ---
Related to PR 10138.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 17:39 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code, wrong-
|
--- Comment #4 from rsandifo at gcc dot gnu dot org 2006-04-11 17:43
---
Subject: Bug 27073
Author: rsandifo
Date: Tue Apr 11 17:43:07 2006
New Revision: 112861
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112861
Log:
PR rtl-optimization/27073
* gcse.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 17:46 ---
This is why Changing reload is hard to do correctly :).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mckinlay at redhat dot com 2006-04-11 18:08 ---
You are correct - I didn't notice that setTcpNoDelay, etc, call getImpl() -
however, this could be fixed if neccessary.
The question is whether this fix is the best one. Is there any disadvantage
(performance or
--- Comment #12 from aph at gcc dot gnu dot org 2006-04-11 18:10 ---
Not worth backporting to 4.0.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-11 18:10 ---
I would not doubt this was PR 26986.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Using built-in specs.
Target: powerpc-apple-darwin8.5.0
Configured with: ../gcc/configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20060411 (experimental)
[dranta:~/tests] dir%
--
Summary: Undefined symbols: ___dso_handle
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 18:20 ---
You need a newer cctools.
See:
http://gcc.gnu.org/ml/gcc/2006-03/msg00507.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Binary operator functions require their arguments to have intent(in).
Gfortran currently doesn't enforce this, ifort does.
$ cat oper-fun.f90
module mymod
interface operator (.foo.)
module procedure foo_int
end interface
contains
function foo_int (a, b)
integer:: foo_int
G++ does not seem to search for classes for friend class declaration outside
the current namespace.
The following code does not work with G++ 4.0.3/4.1.0.
class bar;
namespace NS
{
class foo
{
private:
friend class bar;
static int var;
};
int foo::var = 0;
}
class
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 18:56 ---
You did not read the changes page:
http://gcc.gnu.org/gcc-4.0/changes.html
When declaring a friend class using an unqualified name, classes outside the
innermost non-class scope are not searched:
class A;
This PR was posted to the list by Philippe Schaffnit
http://gcc.gnu.org/ml/fortran/2006-04/msg00131.html
The testcase provided reduces to:
PROGRAM Test
INTEGER :: Array(2, 3) =
reshape ((/1,4,2,5,3,6/),(/2,3/)), Brray(2, 3) = 0
Array(1,:) = Function_Test (Array(1,:))
--- Comment #6 from gerald at gcc dot gnu dot org 2006-04-11 20:09 ---
Subject: Bug 23829
Author: gerald
Date: Tue Apr 11 20:09:32 2006
New Revision: 112865
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112865
Log:
PR libgcj/23829
* configure.ac: Link against
I was writing a routine to shift bits along an array. I want the compiler to
use the shrdl assembler command. It will do this if I load the values into an
(unsigned long long) value, bit it does a whole lot more - taking 22 seconds
to shift 102400 words on an 500MHz Intel PIII. The enclosed C
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-11 20:42 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from csm at gnu dot org 2006-04-11 20:58 ---
I'm not sure I understand your situation. Are you doing:
SecureRandom r = new SecureRandom ();
for (...)
r.getBytes (...); // produces the same bytes each time
Or
for (...)
{
SecureRandom r = new
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-11 21:24 ---
Bootstrapping the fix right now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19719
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-04-11 23:00
---
Subject: Bug 26122
Author: mmitchel
Date: Tue Apr 11 22:59:57 2006
New Revision: 112869
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112869
Log:
* g++.dg/parse/dtor7.C: New test.
*
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-04-11 23:00
---
Subject: Bug 26295
Author: mmitchel
Date: Tue Apr 11 22:59:57 2006
New Revision: 112869
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112869
Log:
* g++.dg/parse/dtor7.C: New test.
*
--- Comment #8 from steven at gcc dot gnu dot org 2006-04-11 23:03 ---
Code size issue
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-04-11 23:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-04-11 23:17
---
Fixed at least on the mainline but still needs to fixed on the 4.1 branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from kazu at gcc dot gnu dot org 2006-04-11 23:47 ---
Subject: Bug 26557
Author: kazu
Date: Tue Apr 11 23:47:35 2006
New Revision: 112870
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112870
Log:
Backport from mainline.
2006-03-13 Roger Sayle
--- Comment #8 from david at jpackage dot org 2006-04-12 00:11 ---
The first case. There is only one instance of SecureRandom. The calls to
nextBytes() are on the same object.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24481
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-12 01:14 ---
GRRR.
This is partly caused by the patch for PR 23669.
(In reply to comment #7)
I disagree. Could you give an explicit example?
Sorry, my mistake, I should not have suggested this testcase: this
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-12 01:17 ---
I don't see any attached sources or .s files.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-04-12 01:18
---
Subject: Bug 26122
Author: mmitchel
Date: Wed Apr 12 01:18:06 2006
New Revision: 112879
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112879
Log:
PR c++/26122
* parser.c
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-12 01:19
---
The ICE is now fixed.
I'm not sure if the failure to diagnose the fact that a non-virtual function
has a pure specifier in a template class is a regression or not.
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-04-12 01:20 ---
The C++ patch fixes the problem with this code and it also finished
bootstrapping without any regression so please test it fully and submit it
instead of your hack.
--
pinskia at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27073
--
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=27044
--
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=26891
--
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=26976
--
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=26779
--
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=25031
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26743
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11254
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10274
--
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=26257
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-04-12 01:24
---
I only have access to the free versions of Intel version 8.0 and version 9.0
and both gave aborted compilation on the test case for ambiguity.
Next step is to check the standards, which I presume Paul has done.
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-12 01:25 ---
Reopening to ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-12 01:25 ---
AS works for me.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-04-12 02:05
---
Subject: Bug 26295
Author: mmitchel
Date: Wed Apr 12 02:05:21 2006
New Revision: 112881
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112881
Log:
PR c++/26295
* decl.c (grokdeclarator):
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-04-12 02:06
---
Fixed in 4.1.1.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 105 matches
Mail list logo