--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-08-04 08:07 ---
This program works for me in both 32 and 64 bit mode.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-08-04
09:04 ---
I'd like to mention a known problem with -frename-registers. Quoting my
analysis for another bug report:
"However the underlying problem is still present and is now visible on x86-64:
the register renami
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-04
09:20 ---
It's an lvalue-cast, which we no longer support as an extension. So it's ICE on
invalid and a frontend bug. The C++ frontend spits out the interesting error
pr23155.c: In function void foo5(int):
pr2315
The following code refuses to compile :
struct C;
template < typename T >
struct B;
template < typename T >
struct A;
void f(const C &c);// this one is fine
void f(const B &a); // this one is fine
void f(const A &a); // this one triggers the bug
void f(double) {}
--- Additional Comments From christian dot joensson at gmail dot com
2005-08-04 09:46 ---
(In reply to comment #24)
> Also fixed in 3.4.5.
This is the currently, 2005-08-03, latest test results I have for 3.4:
http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00196.html
and the gcc PCH
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04
09:51 ---
The liveness analysis in df.c misses the registers marked in
flow.c:mark_regs_live_at_end, so that'd have to be fixed first.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-08-04
10:01 ---
> This is the currently, 2005-08-03, latest test results I have for 3.4:
>
> http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00196.html
>
> and the gcc PCH tests that FAIL are for -m64:
>
> FAIL: gcc.d
--- Additional Comments From gdr at integrable-solutions dot net
2005-08-04 10:02 ---
Subject: Re: New: Error in Koenig Lookup causes overload resolution failure
"adah at netstd dot com" <[EMAIL PROTECTED]> writes:
|
http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_
--- Additional Comments From gdr at integrable-solutions dot net
2005-08-04 10:13 ---
Subject: Re: can't compile self defined void distance(std::vector,
std::vector)
"adah at netstd dot com" <[EMAIL PROTECTED]> writes:
| 1) This bug is not in libstdc++, but in the C++ compiler.
yes
Maybe there are similar issues elsewhere, but this one happened
to bother me... This warning is also issed by GCC 3.3, so I guess
it is not a regression. But it's a silly warning after errors.
=== t.c ===
int bar (void);
int foo (void)
{
int i;
g++ 4.0.1 gives incorrect error message with void function declaration &
implementation when using void main(). This can be demonstrated with the
following program:
--
void f1();
void main()
{
f1();
}
void f1()
{
}
The resulting error message
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-04
11:29 ---
I have a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguen
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-04
11:54 ---
Try killing the peephole2 for this. Somebody elses cost-metric should force
the constant into a register for the move ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23102
--- Additional Comments From joern dot rennecke at st dot com 2005-08-04
12:13 ---
Subject: Re: unrolling does not take target register pressure into account.
steven at gcc dot gnu dot org wrote:
>
>
>
>Could you give some specific examples of assesments that 3.4 can do and 4.1
>c
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-08-04
12:19 ---
This happens again with fresh CVS (20050804). Still no idea?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22097
--- Additional Comments From gdr at integrable-solutions dot net
2005-08-04 12:20 ---
Subject: Re: New: Silly "unused variable" warning after redeclaration of a
local variable
"steven at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| Maybe there are similar issues elsewhere, but
--- Additional Comments From peter at pogma dot com 2005-08-04 12:52
---
New(ish) patch:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00266.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21366
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
13:02 ---
Confirmed, weird.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
13:04 ---
Confirmed, a regression from 3.0.4 and 2.95.3.
--
What|Removed |Added
Status|UNC
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
13:07 ---
IIRC SFINAE does not mean not instantiating the template class.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04
13:10 ---
Strength reduction already happens before loop unrolling, but I guess
there could still be new opportunities after loop unrolling. Not sure
how significant that would be.
For the number of loop iteratio
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
13:14 ---
fmovdne %fcc1, %f50, %f8
Yep this is still a dup of bug 15247.
*** This bug has been marked as a duplicate of 15247 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
13:14 ---
*** Bug 23222 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15247
--- Additional Comments From gdr at integrable-solutions dot net
2005-08-04 13:26 ---
Subject: Re: SFINAE bug
"pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes:
| IIRC SFINAE does not mean not instantiating the template class.
That is true. However, the real issue has noth
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-08-04
13:36 ---
(In reply to comment #13)
> Strength reduction already happens before loop unrolling, but I guess
> there could still be new opportunities after loop unrolling. Not sure
> how significant that would be.
The following file is miscompiled by gcj -C:
public class Outer extends Thread {
public class Inner extends Thread {
private Inner () {
start ();
}
}
}
It uses the wrong "this" to call start():
Outer$Inner(Outer);
Code:
0: aload_0
1: aload_1
2: putfield
--
What|Removed |Added
OtherBugsDependingO||18131, 23220
nThis||
Keywords||
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 15:07
---
Backtrace:
#0 0x08066846 in java_complete_lhs (node=0x0) at
/var/tmp/portage/gcc-4.1.0_beta20050730/work/gcc-4.1-20050730/gcc/java/parse.y:11665
#1 0x08066757 in java_complete_tree (node=0x0) at
/var/tmp/porta
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
15:23 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 15:26
---
The relevant part of the JLS is section 15.12.1 @
http://java.sun.com/docs/books/jls/second_edition/html/expressions.doc.html#20448
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23230
--- Additional Comments From jlquinn at gcc dot gnu dot org 2005-08-04
15:34 ---
Unfortunately, I no longer have access to the test box, so I can't verify if
it's
working now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
when cross compiling the gcc 4.0.2 on a i686-pc-linux-gnu with
intel: binutils 2.16.1 - compiled with gcc 4.1.0
mips: binutils 2.16.1 - compiled with gcc 4.1.0
the following error occures:
/home/pfl/gnu/mips-sgi-irix6.5/bin/ld: unrecognized option '-_SYSTYPE_SVR4'
/home/pfl/gnu/mips-sgi-irix6.5/
gcc version 4.1.0 20050730 (experimental)
The following two DATA statements are rejected by gfortran because "J" is not
considered a valid primary in those expressions although it is the variable of
another enclosing data-implied-do.
PROGRAM p
REAL :: ONE_ARRAY(100, 100)
INTEGER :: K, J
D
--- Additional Comments From rofi at ya dot com 2005-08-04 15:59 ---
Created an attachment (id=9431)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9431&action=view)
Failing case with an optional commented checking part
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23232
This testcase causes an ICE at -O2:
void foo (volatile long long *x)
{
while (*x)
{
*x = 0;
*((volatile char *) 0) = 0;
}
}
with:
error: unrecognizable insn:
(insn:HI 25 21 27 2 (set (mem/v:QI (subreg:SI (reg:DI 124) 4) [0 S1 A8])
(subreg:QI (reg:DI 124) 7)) -1 (ni
--
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |200
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
16:15 ---
Confirmed, I wish loop.c would go away.
--
What|Removed |Added
Known to fail|
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-04 17:06 ---
(In reply to comment #3)
> Try killing the peephole2 for this. Somebody elses cost-metric should force
> the constant into a register for the move ...
Killing the peephole2 would just produce the
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-08-04 17:41 ---
Subject: Re: PCH largefile test fails on various platforms
> Log message:
> ./
> PR pch/14400
> Backport from mainline:
With this change largefile.c now fails on hppa2.0w-hp-hpux
Following test program causes an internal compiler error,
$ cat y.c
double func ( double a, double b, double c)
{
double x0, x1, y0, y1;
int type = 0;
double ar;
if(b==0.0){
x0 = -c/a;
return( x0 > 1.0? 1.0 : ( x0 < 0.0 ? 0.0: x0));
}
if(a==0.0) {
y0 = -c/b;
--- Additional Comments From ian at airs dot com 2005-08-04 17:54 ---
My patch added the largefile test to the 3.4 branch. I don't think that failing
a new test can be called a regression. I expect that the compiler would have
failed the test before, too, it's just that nobody knew abou
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
17:55 ---
Confirmed, reduced testcase:
double func ( double a, double b, double c)
{
double y0;
if(a==0.0) {
y0 = -c/b;
return y0;
}
y0 = -c/b;
return y0;
}
--
What|Removed
--- Additional Comments From uttamp at us dot ibm dot com 2005-08-04 17:57
---
(In reply to comment #1)
> Confirmed, reduced testcase:
> double func ( double a, double b, double c)
> {
> double y0;
> if(a==0.0) {
> y0 = -c/b;
> return y0;
> }
> y0 = -c/b;
> return
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-08-04 18:04 ---
Subject: Re: PCH largefile test fails on various platforms
> My patch added the largefile test to the 3.4 branch. I don't think that
> failing
> a new test can be called a regression. I expect t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-04
18:16 ---
Subject: Bug 22037
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-04 18:16:41
Modified files:
gcc: ChangeLog passes.c tree-cfg.c
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-04
18:17 ---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00283.html.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
18:31 ---
Confirmed, reducing a little further.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
18:43 ---
Reduced testcase:
enum eumtype { ENUM1, ENUM2 };
void g(const eumtype kind );
void f(long i);
void g(const eumtype kind)
{
if ((kind != ENUM1) && (kind != ENUM2))
f(kind);
}
--- the tree before VRP:
--- Additional Comments From danalis at cis dot udel dot edu 2005-08-04
19:16 ---
For the record the reduced test case was derived from h07.cpp of bench++
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22563
--- Additional Comments From dank at kegel dot com 2005-08-04 19:18 ---
In general, once a ten-line testcase is found, do these get added
to the gcc regression testsuite as a matter of course?
We would be happy to submit patches to add these to the test suite, but
we don't have copyrigh
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-04
19:22 ---
When the patch that fixes a bug is put into GCC the testcases go in as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23046
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
19:23 ---
(In reply to comment #8)
> In general, once a ten-line testcase is found, do these get added
> to the gcc regression testsuite as a matter of course?
In general once the fix is found, it will be added to th
--- Additional Comments From dnovillo at redhat dot com 2005-08-04 19:24
---
Subject: Re: [4.1 Regression] ICE in set_value_range, at tree-vrp.c:191
On Thu, Aug 04, 2005 at 07:18:13PM -, dank at kegel dot com wrote:
> In general, once a ten-line testcase is found, do these get add
$ gcc initramfs.i -O2 -c -funit-at-a-time
(...)
init/initramfs.c: At top level:
init/initramfs.c:10: error: message causes a section type conflict
init/initramfs.c:33: error: head causes a section type conflict
init/initramfs.c:80: error: ino causes a section type conflict
init/initramfs.c:
--- Additional Comments From pluto at agmk dot net 2005-08-04 20:40 ---
Created an attachment (id=9433)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9433&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-04 20:48
---
The reason that we're rejecting the "m" alternative is that we've expanded
"+mr"(blen) to
(set (reg/v:SI 60 [ blen.25 ])
(asm_operands:SI ("") ("=mr") 2 [
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
20:58 ---
Reducing.
--
What|Removed |Added
CC||pinskia at
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
FAIL: gcc.c-torture/execute/pr23135.c execution, -Os
(a new test) have appeared on mainline on 20050804 on ia64-hp-hpux11.23, both
-mlp64 and -milp32.
--
Summary: gcc.c-torture/execute/pr23135.c execution fails
Product: gcc
Version: 4.1.0
Status
FAIL: gcc.dg/tree-prof/val-prof-5.c scan-tree-dump Div.mod by constant b..=997
transformation on insn
(a new test) appeared on mainline on 20050802 on hppa2.0w-hpux and hppa64-hpux.
gcc-testresults shows it also failing on hppa-linux.
--
Summary: gcc.dg/tree-prof/val-prof-5.c scan-tr
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:32 ---
Confirmed, reduced testcase:
static __attribute__ ((__section__ (".init.data"))) char *message;
static __attribute__ ((__section__ (".init.data"))) int (*actions[])(void) = {};
void unpack_to_rootfs(void)
{
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:38 ---
Oh, this is truely part of classpath.
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:38 ---
CC tromey.
--
What|Removed |Added
CC||tromey at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:41 ---
I think the easy fix would change Makefile.am.
The following line:
JAVAC = $(srcdir)/split-for-gcj.sh && $(MAKE) -f $(srcdir)/Makefile.gcj \
GCJ='$(GCJ)' compile_classpath='$(top_builddir):$(compile_clas
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:45 ---
This is a classpath issue
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:56 ---
This looks like a target issue.
--
What|Removed |Added
Component|tree-optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
21:57 ---
This looks like a target issue.
--
What|Removed |Added
Component|tree-optimization
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-04 22:03
---
Andrew, can you have a look at why this isn't being TER'ed back into the
asm_expr? It's not a 100% ideal solution to this problem, but I'll guess
that it'll handle at least some of the cases including this one.
--- Additional Comments From greenrd at greenrd dot org 2005-08-04 22:03
---
I'm testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gree
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
22:11 ---
TER will not work at -O0 though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
22:41 ---
This works in "4.1.0 20050802".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-04
22:49 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2005-08-04 23:09 ---
Fixed by this patch:
2005-07-14 Alexandre Oliva <[EMAIL PROTECTED]>
Ulrich Weigand <[EMAIL PROTECTED]>
PR target/20126
* loop.c (loop_givs_rescan): Do
--
Bug 20126 depends on bug 22425, which changed state.
Bug 22425 Summary: [4.1 regression] ICE in loop_givs_rescan, at loop.c:5521
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22425
What|Old Value |New Value
-
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-04
23:37 ---
Subject: Bug 21291
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-04 23:37:00
Modified files:
gcc: ChangeLog tree-outof-ssa.c
Added fil
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-04
23:55 ---
Known.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Eve
The following test code incorrectly generates an assertion failure on gcc
mainline and 4.0.1:
#include
struct fbs {
unsigned char uc8;
} fbs1 = {255};
void testfn ( struct fbs *fbs_ptr )
{
if ((fbs_ptr->uc8 != 255) && (fbs_ptr->uc8 != 0))
assert(0);
}
int main (int argc, char *argv[])
--
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
--- Additional Comments From jconner at apple dot com 2005-08-05 00:17
---
I believe I have tracked down the root of this behavior to an invalid
transformation in simplify_comparison
(from combine.c). See email thread starting here:
http://gcc.gnu.org/ml/gcc/2005-08/msg00159.html
-
Hi,
See the following snippet
[EMAIL PROTECTED]:~$ gcc-snap -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,obj-c++,ada,treelang
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls
--enable-__
On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au
wrote:
/* this one doesn't */
__asm__ __volatile__("xchgb %0, %1"
: "=r"(old), "=m"(*newp)
: "0"(0xff), "m"(*newp) : "memory");
This is not a bug.
r is selecting %sil which is a valid register for x86_64.
"r" is
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-05
01:35 ---
Subject: Re: New: Invalid %sil register chosen when dereferenced pointer used
in inline asm with -O0
On Aug 4, 2005, at 8:32 PM, ianw at gelato dot unsw dot edu dot au
wrote:
> /* this one doesn't
--- Additional Comments From ianw at gelato dot unsw dot edu dot au
2005-08-05 02:17 ---
Subject: Re: Invalid %sil register chosen when dereferenced pointer used in
inline asm with -O0
On Fri, Aug 05, 2005 at 01:35:51AM -, pinskia at physics dot uc dot edu
wrote:
> On Aug 4, 2005
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
02:33 ---
Subject: Bug 21291
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-05 02:33:11
Modified files:
gcc: Change
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 02:34
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-05
02:42 ---
Subject: Bug 21529
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-05 02:42:07
Modified files:
gcc: ChangeLog params.def params.h tree-sr
The iterators over hash_map behave in a manner inconsistent with the other
std::map, std::list, etc... data structures. This can cause segfaults which are
hard to root-cause. Sample Code Included with additional information:
Specifically, the iterators over hash_map require the 'first' datamember
--- Additional Comments From jzampier at gmail dot com 2005-08-05 02:58
---
Created an attachment (id=9434)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9434&action=view)
The offending code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23244
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-05 03:14
---
No, because you still need to use "Q" to get a register that may be used
with a low-part. Even on i486.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:32 ---
*** Bug 23243 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23242
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:35 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:40 ---
Just a note for fullness, this was caused by the patch which fixed PR 19296.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23241
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:43 ---
Fixed by:
2005-08-04 Jan Hubicka <[EMAIL PROTECTED]>
* profile.c (branch_prob): Split edges with goto locus on them
to get proper line counts.
* tree-cfg.c (make_cond_expr_edges):
--- Additional Comments From sethml at google dot com 2005-08-05 03:43
---
The C++ working group examined this issue in April as core language issue 488:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#488
They tentatively concluded that type deduction should fail in this
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:48 ---
Reopening to ...
--
What|Removed |Added
Status|RESOLVED|REOP
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
03:48 ---
To suspend it as the DR is still in drafting.
--
What|Removed |Added
Status|REOP
--- Additional Comments From mark at codesourcery dot com 2005-08-05 03:49
---
Subject: Re: error: '' is/uses anonymous type'
sethml at google dot com wrote:
> --- Additional Comments From sethml at google dot com 2005-08-05 03:43
> ---
> The C++ working group examined this i
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-05
04:02 ---
I don't think this is a bug as A will be tried to be instantiating while
trying to convert it from float.
ICC gives the same result as GCC, an error.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2322
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-
1 - 100 of 118 matches
Mail list logo
