[Bug c++/14379] ICE in tsubst with declaring then defining a member template

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-08 13:05 
---
I've got good news and bad news.

The good news is that the original testcase compiles.

This is most probably due to Mark's patch
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00645.html
http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg00316.html

The bad news is that we now accept the following invalid code:


template  struct X { 
template  void f(T); 
}; 
 
template <> template  void X<1>::f (T); 
template <> template  void X<1>::f (T) {} 
template <> template  void X<1>::f (T) {} // duplicate definition
 
template void X<1>::f(int);


Mark, could you please have a look?


-- 
   What|Removed |Added

 CC||mark at codesourcery dot com
   Keywords||accepts-invalid
  Known to fail|3.3.4 3.4.0 4.0 |3.3.4 3.4.0 4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14379

Re: [Bug tree-optimization/17560] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os

[Diego Novillo]

On Fri, 2004-10-08 at 09:03, sebastian dot pop at cri dot ensmp dot fr
wrote:

> Then the following patch solves the problem by avoiding the analysis
> of these cycles.
> 
You could also try splitting blocks, but if there's a cheaper work
around for 4.0, that'd be safer.


Diego.

[Bug tree-optimization/17560] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os

[dnovillo at redhat dot com]

--- Additional Comments From dnovillo at redhat dot com  2004-10-08 13:09 ---
Subject: Re:  [4.0 Regression] Infinite
recursion in tree-scalar-evolution with -Os

On Fri, 2004-10-08 at 09:03, sebastian dot pop at cri dot ensmp dot fr
wrote:

> Then the following patch solves the problem by avoiding the analysis
> of these cycles.
> 
You could also try splitting blocks, but if there's a cheaper work
around for 4.0, that'd be safer.


Diego.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560

[Bug rtl-optimization/16796] PowerPC - Unnecessary Floating Point Register Copy

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-08 13:11 
---
Confirmed, the problem is related to the register allocator.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-10-08 13:11:12
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16796

[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

[redi at gcc dot gnu dot org]

--- Additional Comments From redi at gcc dot gnu dot org  2004-10-08 13:13 ---
I've finally sent a wwwdocs patch to gcc-patches for approval.

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00736.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953

[Bug c++/14379] ICE in tsubst with declaring then defining a member template

[reichelt at gcc dot gnu dot org]

--- Additional Comments From reichelt at gcc dot gnu dot org  2004-10-08 13:13 
---
Well, we accept the following code since gcc 3.0.
We rejected it in 2.95.x, but for a wrong reason ;-)


template struct A
{
template void foo(T);
};

template<> template void A<0>::foo(T) {}
template<> template void A<0>::foo(T) {}

template void A<0>::foo(int);


So Mark's patch does not introduce a regression.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14379

[Bug tree-optimization/17560] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2004-10-08 13:21 
---
This fix should not be necessary (in fact we had the code like this before, but
I removed it and replaced it by current solution; the problem with is that it
behaves really weird, for example the results are dependent on in which order we
process the variables) -- we check for irreducible regions in scev already. 
Could you check whether the edges are marked as irreducible? If not, this would
be the problem.

Zdenek

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560

[Bug target/17245] [3.3/3.4 regression] ICE compiling gsl-1.5 statistics/lag1.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-08 13:35 
---
Subject: Bug 17245

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-10-08 13:34:57

Modified files:
gcc: ChangeLog 
gcc/config/sparc: sparc.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: ultrasp11.c 

Log message:
PR target/17245
* config/sparc/sparc.c (input_operand): Remove redundant code
for handling LO_SUM.
(legitimate_address_p) : Do not recheck TARGET_V9.
: If LO_SUM is offsettable, accept it for TFmode on V9.
Otherwise only accept it for TFmode if quad move insns are available.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5801&r2=2.5802
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gcc&r1=1.337&r2=1.338
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4410&r2=1.4411
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/ultrasp11.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17245

[Bug target/17245] [3.3/3.4 regression] ICE compiling gsl-1.5 statistics/lag1.c

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-08 13:41 
---
Subject: Bug 17245

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-10-08 13:41:30

Modified files:
gcc: ChangeLog 
gcc/config/sparc: sparc.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/gcc.dg: ultrasp11.c 

Log message:
PR target/17245
* config/sparc/sparc.c (input_operand): Remove redundant code
for handling LO_SUM.
(legitimate_address_p) : Do not recheck TARGET_V9.
: If LO_SUM is offsettable, accept it for TFmode on V9.
Otherwise only accept it for TFmode if quad move insns are available.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.649&r2=2.2326.2.650
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sparc/sparc.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.271.4.20&r2=1.271.4.21
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.278&r2=1.3389.2.279
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/ultrasp11.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17245

[Bug target/17245] [3.3 regression] ICE compiling gsl-1.5 statistics/lag1.c

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-10-08 13:48 
---
See http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00743.html

I don't plan to have it fixed on the 3.3 branch as it is not a critical problem
and there is a simple workaround (compiling with -mcpu=v8).  Not worth the risk
at this point IMHO.


-- 
   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[3.3/3.4 regression] ICE|[3.3 regression] ICE
   |compiling gsl-1.5   |compiling gsl-1.5
   |statistics/lag1.c   |statistics/lag1.c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17245

[Bug tree-optimization/17560] [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os

[sebastian dot pop at cri dot ensmp dot fr]

--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr  2004-10-08 
13:49 ---
Subject: Re:  [4.0 Regression] Infinite recursion in tree-scalar-evolution with -Os

> Could you check whether the edges are marked as irreducible? If not, this would
> be the problem.
> 

Indeed, both edges for the phi "i_2 = phi (i_4, i_1)" are not marked
by EDGE_IRREDUCIBLE_LOOP, and consequently backedge_phi_arg_p returns
always false.  Same for the first edge i_1 -> i_2 of "i_1 = phi (i_2,
i_7)" that is not marked as EDGE_IRREDUCIBLE_LOOP.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17560

[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

[carlo at gcc dot gnu dot org]

--- Additional Comments From carlo at gcc dot gnu dot org  2004-10-08 13:53 ---
This wording is very boost specific and does not give
a solution for other libraries that need to detect
at prepocessing time whether or not -pthread is
being used.

Consider a library libjohndoe, this library comes in two
flavours: one that is not thread-safe (-ljohndoe) and
one that is thread-safe, but considerably slower and
larger so that users really only want to use it when
they are actually using threads (-ljohndoe_r).

The header files of libjohndoe also need to adjust
prototypes and macros based on whether a user is linking
with -ljohndoe or -ljohndoe_r, so a macro is needed.
If that macro is not provided by -pthreads, then the
users of libjohndoe will be forced to provide it themselfs:

g++ app.cc -ljohndoe

or

g++ -pthread app.cc -DMT_JOHNDOE -ljohndoe_r -lpthread

In my opinion that is the same as when users of Tru64
are forced to define _REENTRANT when including pthread.h
and when that is not acceptable then forcing user-defined
macros to be defined in order to tell whether or not
an application is expected to be thread-safe (while previous
this was not necessary) seems at least to be undesirable.

Most importantly however - it is totally unnecessary.
At all times there will be this -pthread commandline
option that imho has exactly the meaning that we are
looking for: This application is using threads and needs
thread-safe libraries.

Wouldn't it be a very reasonable and logical solution
to define some, any, macro when -pthread is used on the
command line?  It would solve my problem and it would
solve boosts problem, and it would solve the problem
of the author of libjohndoe too.

I think this new macro really must be added to 4.0.0
before its release.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953

[Bug c/17870] Compiling linux-2.6.8.1: internal compiler error: Segmentation fault

[pander at users dot sourceforge dot net]

--- Additional Comments From pander at users dot sourceforge dot net  2004-10-08 
14:18 ---
Tried to get the *.i* files with the -save-temps option to complete bug report. 
Meanwhile I got an upgrade from gcc via apt-get and the problem has (luckily) 
disappered.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17870

[Bug tree-optimization/17884] [4.0 Regression] asm 'volatile' is not honored as documented

[amacleod at redhat dot com]

--- Additional Comments From amacleod at redhat dot com  2004-10-08 14:35 ---
So after a discussion, I dont think the patch will be applied.  

A follow on sentence in the documentation reads:

"Note that even a volatile asm instruction can be moved in ways
that appear insignificant to the compiler, such as across jump
instructions.  You can't expect a sequence of volatile asm
instructions to remain perfectly consecutive.  If you want consecutive
output, use a single asm.  Also, GCC will perform some
optimizations across a volatile asm instruction; GCC does not
``forget everything'' when it encounters a volatile asm
instruction the way some other compilers do."


Thats what it is doing in this case, we are moving unrelated instructions across
the volatile asm. 

RTH suggested that we remove the sentence "In addition, GCC will not reschedule
instructions across a volatile asm instruction." from the documention since it
is incorrect given the above note.

It you need instructions not to be moved across a volatile, they must be exposed
in the asm.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17884

[Bug preprocessor/15824] [4.0 Regression] uchar redefinition warnings in libcpp

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-08 14:50 
---
Does this still happen?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15824

[Bug c++/17873] [3.3/3.4/4.0 Regression] order of static destructors wrong

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-10-08 14:58 ---

Agggh! Sorry everybody. My testing was flawed: I just discovered a typo in my
config files for gcc builds. I was using --enable-_cxa_atexit instead of
--enable-__cxa_atexit. (Two underscores.)

Ughh!

Hopefully this will resolve this issue. Sorry again for the false alarm.

-benjamin


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17873

[Bug preprocessor/15824] [4.0 Regression] uchar redefinition warnings in libcpp

[ro at techfak dot uni-bielefeld dot de]

--- Additional Comments From ro at techfak dot uni-bielefeld dot de  2004-10-08 
15:10 ---
Subject: Re:  [4.0 Regression] uchar redefinition warnings in libcpp

pinskia at gcc dot gnu dot org writes:

> Does this still happen?

It did when I last bootstrapped mainline on alpha-dec-osf5.1b as of
20040910.

Rainer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15824

[Bug c++/17873] [3.3/3.4/4.0 Regression] order of static destructors wrong

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-08 15:11 ---
> Agggh! Sorry everybody. My testing was flawed: I just discovered a typo in my
> config files for gcc builds. I was using --enable-_cxa_atexit instead of
> --enable-__cxa_atexit. (Two underscores.)

Thanks. Now things are much more clear.

> Hopefully this will resolve this issue.

About this, however, I'm really unsure! If that option is meaningful only with
glibc, this implies logically that the allocator is broken on anything not
using glibc?!? Or we should fix it not to rely on the order of destruction?!?
 
I'm really worried by these new (for me, I mean) problems...

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17873

[Bug c++/17873] [3.3/3.4/4.0 Regression] order of static destructors wrong

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-10-08 15:17 ---

No, it just means we check for _GLIBCXX_USE___CXA_ATEXIT in mt_allocator.cc, and
if it's not defined we don't have any definitions for ~__pool. That will resolve
this issue.

I'll take care of this today, but give me some time to rebuild all my trees and
(correctly) test.

-benjamin

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17873

[Bug c++/17873] [3.3/3.4/4.0 Regression] order of static destructors wrong

[pcarlini at suse dot de]

--- Additional Comments From pcarlini at suse dot de  2004-10-08 15:19 ---
> No, it just means we check for _GLIBCXX_USE___CXA_ATEXIT in mt_allocator.cc, and
> if it's not defined we don't have any definitions for ~__pool. That will resolve
> this issue.

That makes perfect sense, indeed!

Thanks!
Paolo.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17873

[Bug c++/17829] [3.4 Regression] wrong error: call of overloaded function is ambiguous

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-08 15:20 
---
Subject: Bug 17829

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-10-08 15:19:57

Modified files:
gcc/cp : ChangeLog parser.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/lookup: koenig4.C 

Log message:
cp:
PR c++/17829
* parser.c (cp_parser_postfix_expression): Inhibit Koenig when
unqualified lookup finds a member function.
testsuite:
PR c++/17829
* g++.dg/lookup/koenig4.C: New.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.162&r2=1.3892.2.163
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.41&r2=1.157.2.42
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.279&r2=1.3389.2.280
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/lookup/koenig4.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.4.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17829

[Bug c++/17873] [3.3/3.4/4.0 Regression] order of static destructors wrong

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-10-08 15:34 ---

Indeedy. All fixed. I'm closing this now, more than slightly embarrassed.

-benjamin

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17873

[Bug c++/17873] [3.3/3.4/4.0 Regression] order of static destructors wrong

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-10-08 15:36 ---

User deliriousness.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17873

[Bug tree-optimization/17892] New: gcc-4.0 should not reassociate floating point add or multiplication

[fjahanian at apple dot com]

In the following code the repeated multiplication is folded into a single operation 
(multiplication by Infinity). 
For different values of "x" this leads to undeserved or absent floating point 
exceptions, and 
breaks some of the elementary math functions in Libm. Occurs at optimization O1 and 
higher. 

static const double C = 0x1.0p1023;

double foo(double x)
{
return ( ( (x * C) * C ) * C );
}

-- 
   Summary: gcc-4.0 should not reassociate floating point add or
multiplication
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P1
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fjahanian at apple dot com
CC: gcc-bugs at gcc dot gnu dot org,roger at eyesopen dot
com
 GCC build triplet: powerpc-apple-darwin
  GCC host triplet: powerpc-apple-darwin
GCC target triplet: powerpc-apple-darwin


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17892

[Bug tree-optimization/17884] [4.0 Regression] asm 'volatile' is not honored as documented

[fjahanian at apple dot com]

--- Additional Comments From fjahanian at apple dot com  2004-10-08 16:23 ---
But this is a regression from gcc-3.3. Also, without this patch, there is no other 
place which checks
for a volatility of an 'asm' statement. Then why not just say in the documentation 
that 'volatile'
has no effect on an 'asm'? BTW, thanks for preparing the patch for me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17884

[Bug rtl-optimization/15632] Failure to unroll loop when using FDO causes performance regression

[steinmtz at us dot ibm dot com]

--- Additional Comments From steinmtz at us dot ibm dot com  2004-10-08 16:28 
---
It appears that the specific problem documented here has been resolved in 
mainline.  There is still a performance regression when using FDO, however, 
but it must be for other reasons.

Marking this one as resolved and will work on figuring out what is the current 
cause of the regression.

-- 
   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15632

[Bug rtl-optimization/15632] Failure to unroll loop when using FDO causes performance regression

[reichelt at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15632

[Bug tree-optimization/17892] [4.0 Regression] gcc-4.0 should not reassociate floating point add or multiplication

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-08 16:59 
---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2004-10-08 16:59:47
   date||
Summary|gcc-4.0 should not  |[4.0 Regression] gcc-4.0
   |reassociate floating point  |should not reassociate
   |add or multiplication   |floating point add or
   ||multiplication
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17892

[Bug c/16999] [3.4/4.0 Regression] #ident stopped working

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-10-08 17:04 
---
Patch posted here: .

Mine.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords||patch
  Known to fail|3.4.0 4.0   |3.4.0 4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16999

[Bug libstdc++/17864] [4.0 Regression] deallocate_global

[bkoz at gcc dot gnu dot org]

--- Additional Comments From bkoz at gcc dot gnu dot org  2004-10-08 17:07 ---

I still think the scope of this problem is wrong. This is likely an AIX-only
issue. At least, I cannot reproduce this on other platforms like darwin, or
cross compilers.

This compile error is confusing to me: it seems to point to something is up with
thread configs on AIX, just because of the files that are failing. However, the
line numbers don't match up to that. It doesn't look like it's choking on the
definition of the thread-enabled pool, which assumes _GTHREADS. 

How could this be happening? Can you pre-process one of these files and stick it
in bugzilla please?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17864

[Bug libstdc++/17755] Can't compile djgpp cross-compiler

[psychonaut at nothingisreal dot com]

--- Additional Comments From psychonaut at nothingisreal dot com  2004-10-08 17:18 
---
The fix suggested by Andris Pavenis does not work for me.  Even when the
directory $prefix/lib/gcc/$target/$version (in this case
/usr/local/compiler/cross/djgpp/lib/gcc/i586-pc-msdosdjgpp/3.4.2) exists at
configure time, I get the same build error upon make.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17755

[Bug c++/17829] [3.4 Regression] wrong error: call of overloaded function is ambiguous

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-10-08 17:43 
---
Fixed in GCC 3.4.3 and GCC 4.0.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17829

[Bug c++/17801] [3.4 Regression] segfault in perform_or_defer_access_check

[giovannibajo at libero dot it]

-- 
Bug 17801 depends on bug 17829, which changed state.

Bug 17829 Summary: [3.4 Regression] wrong error: call of  overloaded function is 
ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17829

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17801