--- Additional Comments From uros at kss-loka dot si 2005-01-19 08:17
---
This functionality is missing after FP compares rewrite:
==i386_old.md==
...
;; We can't represent the LT test directly. Do this by swapping the operands.
(define_split
[(set (match_operand:SF 0 "fp_register_
during bootstrap the compiler warns:
../../../libgfortran/generated/matmul_l4.c:102: warning: 'astride' is used
uninitialized in this function
../../../libgfortran/generated/matmul_l4.c:109: warning: 'bstride' is used
uninitialized in this function
../../../libgfortran/generated/matmul_l8.c:
The new flat layout of the multilibed libgcc_s shared library in the build tree
has broken in-tree multilib testing on IRIX and Solaris because there are now
multiple shared objects with the same soname in the same directory.
Richard Sandiford's analysis for IRIX and plausible kludge:
http://gcc.g
BUG REPORTS HAVE TO CONTAIN AT LEAST THE FOLLOWING INFORMATION IN ORDER TO BE
USEFUL:
the exact version of GCC, as shown by "gcc -v";
gcc -v
Reading specs from C:/languages/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --
--
What|Removed |Added
CC||rsandifo at redhat dot com,
||zack at codesourcery dot com
http
--- Additional Comments From pcarlini at suse dot de 2005-01-19 09:09
---
> Does this behaviour seem a little bit unusual to you? You said: "You
> cannot create a basic_string object in memory aligned one".
> That is rather counter-intuitive to a user of libstdc++ who has no
> understan
--- Additional Comments From stevenb at novell dot com 2005-01-19 09:12
---
Subject: Re: DSE is not doing its job for global variables
Do you happen to have numbers on how many dead stores the RTL dead
store elimination (in flow.c, right) catches?
--
http://gcc.gnu.org/bugzilla/
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
09:27 ---
Subject: Bug 19164
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-19 09:27:24
Modified files:
gcc: ChangeLog c-typeck.c gimplify.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
09:27 ---
Subject: Bug 17297
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-19 09:27:24
Modified files:
gcc: ChangeLog c-typeck.c gimplify.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
09:31 ---
Subject: Bug 15139
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-19 09:31:16
Modified files:
gcc: ChangeLog Makefile.in combine.c param
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-19 09:34
---
Reopening PR, as the report supposedly referred to in comment #9
was with native tools (/usr/ccs/bin something).
I hope to close this PR in a day or two pending a bootstrap with gas+ld.
--
What|
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
09:45 ---
Subject: Bug 17297
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-01-19 09:44:49
Modified files:
gcc: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
09:45 ---
Subject: Bug 19164
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-01-19 09:44:49
Modified files:
gcc: Change
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-19 09:49
---
Fixed in CVS.
--
What|Removed |Added
Status|NEW |RESOLVED
installing with DESTDIR set to a temporary installation directory, the
installation fails when relinking libgij. The failure is hidden, if libgcj can
be found elsewhere on the system.
Matthias
libtool: install: warning: relinking `libgij.la'
(cd /home/packages/gcc/4.0/gcc-4.0-4.0ds4/build/i486-
Today's (2005-01-19) gcc trunk does not build for sh-rtems*:
...
make[1]: Entering directory
`/users/rtems/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc'
gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -W
--
What|Removed |Added
Target Milestone|3.4.4 |3.3.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19164
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-01-19
09:55 ---
At the risk of stating the obvious, I think this is wider than just
Solaris and IRIX. Build-directory testing is broken for similarly-
organised *-linux-gnu configurations too. I think it's less likely
to
RTEMS is relying on the set of multilibs having been used by default before
gcc-4.0.0, i.e.
# sh-rtems-gcc --print-multi-lib
.;
ml;@ml
m2;@m2
m3e;@m3e
m4-single-only;@m4-single-only
m4-single;@m4-single
m4;@m4
ml/m2;@[EMAIL PROTECTED]
ml/m3e;@[EMAIL PROTECTED]
ml/m4-single-only;@[EMAIL PROTECTED]
--- Additional Comments From pcarlini at suse dot de 2005-01-19 10:05
---
Well, I can see that basic_string default allocator, std::allocator
according to the standard shall return memory only aligned as CharT requests,
not more; whereas our implementation of std::allocator provides stro
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-19
10:13 ---
Confirmed by Richard.
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
11:18 ---
Subject: Bug 15139
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-01-19 11:18:20
Modified files:
gcc: Change
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-19 11:21
---
Fixed in CVS.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pcarlini at suse dot de 2005-01-19 11:51
---
For 4.0, besides the documentation issue, I think we should change
ext/array_allocator to use tr1::type_traits::aligned_storage, finally
available. I will post a patch ASAP...
--
What|Removed
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-19
12:21 ---
I am not even going to try and look surprised, the SH port is a major
abuser of the middle-end. But of course, hard_regs_intersect_p should
have been in hard-reg-set.h from the start, *sigh*, mess-meets-me
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-19
12:26 ---
...and remove the #include "ra.h" of course.
Paolo, you should also update doc/passes.texi, which also still
has references to new-ra.
--
What|Removed |Added
--
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-19
12:37 ---
As this bug is blocking some of my code, I did some testing of the patch
provided in comment #2. Bootstrapped and no additional regression on
sparc-sun-solaris2.9. It fixes the testcase all right. Thanks!
--- Additional Comments From coudert at clipper dot ens dot fr 2005-01-19
12:38 ---
I tested the patch from comment #8. Bootstrapped and regtested on
sparc-sun-solaris2.9. This fixes the intrinsic_transpose.f90 failure all right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19294
--- Additional Comments From bauhaus at futureapps dot de 2005-01-19 12:40
---
Created an attachment (id=7990)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7990&action=view)
test case as a file attachment, as requested
also triggered by this compiler:
+===
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-01-19 12:55 ---
Subject: Re: [4.0 regression] missing ra.h
steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org 2005-01-19
> 12:26 ---
> ...and remove the #
--- Additional Comments From ch at csh-consult dot dk 2005-01-19 13:06
---
Does this mean that there is a limit to how many files you can compile at a
time (due to limited memory)? Can't the garbage collector run between each
compilation?
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-01-19
13:27 ---
I've fixed the doc/passes.texi (commit in progress).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
--
What|Removed |Added
Keywords||build
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19525
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-01-19
13:47 ---
Steven, building cc1 to sh-unknown-elf with your patch succeeded.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
--
What|Removed |Added
Keywords||build
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
13:57 ---
(In reply to comment #5)
> Does this mean that there is a limit to how many files you can compile at a
> time (due to limited memory)? Can't the garbage collector run between each
> compilation?
Yes for l
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
14:01 ---
To me it looks like a libtool bug but I could be wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19527
--
What|Removed |Added
Component|bootstrap |target
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1952
--
What|Removed |Added
Priority|P2 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19529
--
What|Removed |Added
Priority|P2 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
14:30 ---
Subject: Bug 19375
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-19 14:30:24
Modified files:
gcc/cp : ChangeLog semantics.c
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
14:46 ---
Subject: Bug 19258
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-01-19 14:46:35
Modified files:
gcc/cp : Change
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-19
14:47 ---
Fixed in 3.4 branch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
14:50 ---
Subject: Bug 19375
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-01-19 14:50:27
Modified files:
gcc/cp : Change
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-19
14:51 ---
Fixed in 3.4 branch and mainline.
--
What|Removed |Added
Status|ASSIGNED
When I compile this code :
#include
__m64 moo(int i) {
__m64 tmp = _mm_cvtsi32_si64(i);
return tmp;
}
With (GCC) 4.0.0 20050116 like so:
gcc -O3 -S -mmmx moo.c
I get this (without the function pop/push etc)
movd12(%ebp), %mm0
movq%mm0, (%eax)
However, if I use the
--- Additional Comments From guardia at sympatico dot ca 2005-01-19 14:59
---
Created an attachment (id=7991)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7991&action=view)
gcc -O3 -S -msse moo.c --save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
Keywords||missed-optimization, ssemmx
http:/
--
What|Removed |Added
Component|regression |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
15:07 ---
Hmm, looking at the rtl dumps this looks like the register allocator sucks as
the sse register is picked in
the -msse but in the -mmmx, only the mmx register is picked. Someone needs to
take an axe to th
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-01-19
15:17 ---
Testing a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsa
RVO is performed on a temporary object that is declared volatile.
That seems contradictory with the ISO standards 12.8 15 (object and copy must
have the same cv-unqualified type).
With the following piece of code, I was excepting the copy constructor and
destructor to be called.
struct String
{
Note that do_pending_inlines has been removed with
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg01574.html
However, cp/pt.c still mentions do_pending_inlines like so
/* Returns 1 if processing DECL as part of do_pending_inlines
needs us to push template parms. */
static int
inline_needs_tem
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
15:38 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
15:39 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From ian at airs dot com 2005-01-19 15:51 ---
Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01223.html
--
What|Removed |Added
--- Additional Comments From gdr at integrable-solutions dot net
2005-01-19 15:57 ---
Subject: Re: basic_string::_M_rep() can produce an unnaturally aligned pointer
to _Rep
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| > Does this behaviour seem a little bit unusual to you?
--- Additional Comments From gdr at integrable-solutions dot net
2005-01-19 16:02 ---
Subject: Re: basic_string::_M_rep() can produce an unnaturally aligned pointer
to _Rep
"pcarlini at suse dot de" <[EMAIL PROTECTED]> writes:
| Well, I can see that basic_string default allocator, st
--- Additional Comments From law at redhat dot com 2005-01-19 16:22 ---
Subject: Re: DSE is not doing its job for
global variables
On Wed, 2005-01-19 at 09:12 +, stevenb at novell dot com wrote:
> --- Additional Comments From stevenb at novell dot com 2005-01-19 09:12
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-19
16:35 ---
(In reply to comment #5)
> Steven, building cc1 to sh-unknown-elf with your patch succeeded.
Building sh-rtems4.7 with Steven's patch also succeeds.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
16:41 ---
Subject: Bug 19462
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-19 16:39:27
Modified files:
gcc: ChangeLog reorg.c
Log message:
In the headers from gcc for Windows, the file commdlg.h doesn't contain
START_PAGE_GENERAL's constant.
(use with the structure PRINTDLGEX -
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/userinput/commondialogboxlibrary/commondialogboxreference/c
--
What|Removed |Added
Summary|Win32 API START_PAGE_GENERAL|START_PAGE_GENERAL
|constant not exists |
http://gcc.gnu.org/bugzilla/show_bug.cgi?
I build gcc from the actual snapshot gcc-4.0-20050116.
When I compile boost_1_32_0 I get an ICE when I execute the self tests:
Michael Cieslinski
g++ -c -o bienstman1.o bienstman1.ii
/home/cie019/boost/boost_1_32_0/boost/python/detail/destroy.hpp: In static
member function 'static void
boost
--- Additional Comments From micis at gmx dot de 2005-01-19 16:48 ---
Created an attachment (id=7992)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7992&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19534
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-19
17:04 ---
Mark, your response addresses the original message but not the later ones, and
not either of the attached test cases. In those the class is:
class bc {
public:
char m1 :17;
};
m1 is assigned a value of
In tr1/utility:
template<>
struct __pair_get<1>
{
template
static _Tp1& __get(std::pair<_Tp1, _Tp2>& __pair)
{ return __pair.second; }
template
static const _Tp1& __const_get(const std::pair<_Tp1, _Tp2>& __pair)
{ return __pair.second; }
};
These
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-19
17:04 ---
Subject: Bug 19462
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-19 17:04:25
Modified files:
gcc/testsuite : ChangeLog
gcc/testsuite/gcc.
--- Additional Comments From peturr02 at ru dot is 2005-01-19 17:06 ---
Created an attachment (id=7993)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7993&action=view)
Test case
Compiling this fails with:
g++0116 -Wall -static 1.cc -o 1
/usr/local/lib/gcc/i686-pc-linux-gnu/4.0
--- Additional Comments From stuart at apple dot com 2005-01-19 17:08
---
> So the bug is the end stab without the start stab?
Yes.
> Or do you think that this
> bit of code that corresponds not at all to any user code should have full
> stabs?
My personal preference is a mild "yes."
I build gcc from the actual snapshot gcc-4.0-20050116.
When I compile boost_1_32_0 I get an ICE when I execute the self tests.
This ICE only occurs if I use the "-g" option.
Michael Cieslinski
g++ -g -c -o current_function_test.o current_function_test.ii
../libs/utility/test/../current_function_
--- Additional Comments From micis at gmx dot de 2005-01-19 17:11 ---
Created an attachment (id=7994)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7994&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19536
--- Additional Comments From hp at gcc dot gnu dot org 2005-01-19 17:18
---
All committed to main trunk.
(May reopen for branches.)
--
What|Removed |Added
Status
This does not appear to be the same as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14436.
binutils 2.15, gcc from CVS as or 2005-01-19.
This should be reproducible in any other tic4x target.
./gcc/configure --target=tic4x-rtems4.7 --enable-threads=rtems
--prefix=/opt/rtems-test --with-gnu-as --w
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:24 ---
Tru64 is not a primary or secondary platform; removing target milestone.
--
What|Removed |Added
-
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:32 ---
MMIX is not a primary or secondary target; removing target milestone.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
18:38 ---
Not a gcc bug, report this either to cygwin or mygwin as they provide the
headers.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
18:39 ---
*** Bug 19534 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
18:38 ---
I already reduced this, this is a dup of bug 19299.
*** This bug has been marked as a duplicate of 19299 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
18:41 ---
This is a dup of bug 19367 which is already reduced.
*** This bug has been marked as a duplicate of 19367 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
18:41 ---
*** Bug 19536 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:43 ---
SH is not a primary or secondary target; removing target milestone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:45 ---
This option is only designed for use in debugging the compiler. As it's not
designed for use by end-users, I've removed the target milestone.
--
What|Removed |Added
--
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:47 ---
MMIX is not a primary or secondary platform; removing target milestone.
--
What|Removed |Added
--
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:47 ---
MMIX is not a primary or secondary platform; removing target milestone.
--
What|Removed |Added
--
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:47 ---
MMIX is not a primary or secondary platform; removing target milestone.
--
What|Removed |Added
--
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:51 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
18:52 ---
Ada and Java bugs are not release-critical; therefore, I've removed the target
milsetone.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-19
18:59 ---
Good. Ralf, can you post it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-19
19:24 ---
Mark, can we keep known wrong-code bugs targeted for 4.0 please? Java/Ada
or other languages shouldn't make a difference for wrong code bugs. They
are the most serious kind we have.
--
Wha
--- Additional Comments From leehod at il dot ibm dot com 2005-01-19 19:28
---
There is now a patch addressing these issues.
See: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01247.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18441
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
19:32 ---
I just to be able to reproduce this all the time too but lately (in the last
two months) I have not been
able to so closing as fixed.
--
What|Removed |Added
---
--- Additional Comments From andreev at comm dot mot dot com 2005-01-19
19:33 ---
There is no config.log file in libstdc++ directory. And I have
target's /usr/lib and /usr/include directories in location specified by --with-
sysroot
--
What|Removed |
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
19:36 ---
This config.log:
./i686-pc-solaris2.8/libstdc++-v3/config.log
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19492
--- Additional Comments From andreev at comm dot mot dot com 2005-01-19
19:38 ---
(In reply to comment #5)
> This config.log:
> ./i686-pc-solaris2.8/libstdc++-v3/config.log
Andrew, there is no such file, look at comment #2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19492
1 - 100 of 166 matches
Mail list logo
