Andrew Pinski [EMAIL PROTECTED] wrote on 20/09/2005 18:09:20:
On Sep 20, 2005, at 3:01 AM, Dorit Naishlos wrote:
We've had the testcase below in autovect-branch for a while, testing
that
the 3 loops get vectorized. On mainline the third loop now gets
eliminated
by DCE (.t44.dce3).
Hi,
There is a little progress. I find it's concerned with gcc optimize.
When I change the option -O2 to -O0, it passes the make. Of
course, I'd like to say there are something wrong in my backend.
But, can somebody give me any clue?
Thanks.
Eric
Ernest L. Williams Jr. wrote:
Hi,
The following code fragment is now causing problems under gcc 4.0.1
Everything is perfect under gcc version 3.4.3
Any recommended work-arounds?
= code fragment==
#ifndef __LOC_PV_FACTORY_H__
#define
On Wed, 2005-09-21 at 10:51 +0200, Paolo Bonzini wrote:
Ernest L. Williams Jr. wrote:
Hi,
The following code fragment is now causing problems under gcc 4.0.1
Everything is perfect under gcc version 3.4.3
Any recommended work-arounds?
= code
Hi,
I have compiled a testcase
int main()
{
enum aa {
a = 0, b =127 , c
};
printf(size = %d %d %d\n, sizeof(a),sizeof(b), sizeof(c));
printf(value= %d %d %d\n, a,b,c);
return 0;
}
On gcc (GCC) 4.1.0 20050915 (experimental) with the following
On Wed, Sep 21, 2005 at 05:46:58PM +0530, Gaurav Gautam, Noida wrote:
int main()
{
enum aa {
a = 0, b =127 , c
};
printf(size = %d %d %d\n, sizeof(a),sizeof(b), sizeof(c));
printf(value= %d %d %d\n, a,b,c);
return 0;
}
The option
I'm soliciting feedback regrading a problem in the 4.0.2 release.
PR 23993 is a rejects-valid C++ PR that represents a regression from
GCC 4.0.1. That's particularly unfortunate; we really want to avoid
introducing new breakage on the release branch.
It is, sadly, more fallout from my static
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
TJ Laurenzo wrote:
I'm getting a segmentation fault in the GCC build from today's CVS
HEAD. I am building the suite for mingw using a cross compiler from
Linux. This setup was working fine prior to updating to the latest
CVS head today. My old
On Wed, Sep 21, 2005 at 07:03:49PM +0530, Gaurav Gautam, Noida wrote:
Thanks for the reply,
But why is there a difference in the output of same tc, with an old gcc
compiler and a new version of compiler.
Was there a bug in the earlier gcc.
I have a doubt.
Gcc manual says that
On Wed, 2005-09-21 at 16:40 +0800, Eric Fisher wrote:
Hi,
There is a little progress. I find it's concerned with gcc optimize.
When I change the option -O2 to -O0, it passes the make. Of
course, I'd like to say there are something wrong in my backend.
But, can somebody give me any clue?
So, my options are:
1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
on my disk.)
2. Apply the patch, respin the release, and release it.
3. Apply the patch, spin RC3, and go through another testing cycle.
My current plan is (2) because I think that this is an
1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
on my disk.)
Let's drop-kick this sucker to the ftp server already.
Has Benjamin applied his patch on the 4.0 branch?
I have. I am awaiting solaris test details.
-benjamin
Gaurav Gautam, Noida [EMAIL PROTECTED] writes:
Does -fshort-enum guides the size of enumeration type or the size of
enumerator constant ?
An enumerator constant is not an object, thus it has no size of its own.
Since the enumerator constants are of type int, not the enum type,
-fshort-enum
Mark Mitchell [EMAIL PROTECTED] wrote:
1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
on my disk.)
2. Apply the patch, respin the release, and release it.
3. Apply the patch, spin RC3, and go through another testing cycle.
My feeling is that these 4.0 releases
As a follow up to http://gcc.gnu.org/ml/gcc/2005-04/msg00461.html
I would like to improve SMS by passing data dependencies information
computed in tree-level to rtl-level SMS. Currently data-dependency graph
built for use by SMS has an edge for every two data references (i.e. it's
too
I was wondering if I could get some help/advice from a testsuite expert.
I have a patch that I want to submit that makes sure elements of an
array are not given an alignment greater than their size.
See http://gcc.gnu.org/ml/gcc/2005-03/msg00729.html
This test was causing a bunch of regressions,
Rainer Emrich [EMAIL PROTECTED] writes:
/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/xgcc
-
-B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/gcc-4.0.1-test/gcc-4.0.1-test/gcc/
- -B/SCRATCH/gcc-build/IRIX64/mips-sgi-irix6.5/install/mips-sgi-irix6.5/bin/
-
On Wed, Sep 21, 2005 at 10:54:56AM -0400, Robert Dewar wrote:
Daniel Jacobowitz wrote:
I'm not 100% sure what #3 means for enumerators whose value does not
fit in the range of int, but it's pretty clear that the
implementation is not allowed to change the type of enumerators.
Of course an
L.S.,
The host of my domain has been forcefully upgraded to an HP zv6025,
sporting an Athlon 64 processor, 512 Mbyte of memory and 60 Gbytes
of disk.
The upgrade took so long (2.5 months) because I was determined to
run Debian AMD64 on it (the hardware was delivered next day).
Coming weekend
Yao Qi [EMAIL PROTECTED] writes:
Make distclean can not remove intl/config.cache and fixincludes/config.cache.
The configure commandline I used in GCC building is
../gcc-dfp-cvs-Aung-10/configure --enable-languages=c --enable-shared
--enable-threads=posix --enable-checking
[EMAIL PROTECTED] (Per Abrahamsen) wrote on 19.09.05 in [EMAIL PROTECTED]:
Robert Dewar [EMAIL PROTECTED] writes:
Per Abrahamsen wrote:
The idea was that you would be sure to get all the (boolean) warnings
that are relevant for your project, and can give an explicit reason
for each
Incidentally, any time I've done this, I wanted labels on warnings
as to what option was responsible
-fdiagnostics-show-option
Correlating the stacktrace with CVS revealed that this was fixed a few
hours after I updated. The bug was 23929.
Ranjit, thanks for the help getting the debugger going.
TJ
Tom Tromey wrote:
I'm finally ready to do another classpath import,
Do you plan on another classpath import before the 4.1 release?
David Daney.
Giovanni Bajo wrote:
Mark Mitchell [EMAIL PROTECTED] wrote:
1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
on my disk.)
2. Apply the patch, respin the release, and release it.
3. Apply the patch, spin RC3, and go through another testing cycle.
My humble opinion
Mike Stump wrote:
On Friday, September 16, 2005, at 10:19 AM, Jonathan Turkanis wrote:
I think I can give you an answer which is completely correct and yet
completely useless: -fvisibility=default is supported on every platform.
Thank you -- it's not completely useless.
It is.
I
Richard Henderson [EMAIL PROTECTED] writes:
* builtin-types.def (BT_PTR_LONG, BT_PTR_PTR, BT_FN_BOOL, BT_FN_INT,
BT_FN_VOID_PTRPTR, BT_PTR_FN_VOID_PTR, BT_FN_VOID_UINT_UINT,
BT_FN_BOOL_LONGPTR_LONGPTR, BT_FN_VOID_OMPFN_PTR_UINT,
BT_FN_VOID_OMPFN_PTR_UINT_UINT,
Geoffrey Keating wrote:
Jonathan Turkanis [EMAIL PROTECTED] writes:
Geoffrey Keating wrote:
Jonathan Turkanis [EMAIL PROTECTED] writes:
If you tell us what the real question is, maybe we can answer that one.
To me, that sounds like an insult: why do you think I wouldn't ask the
real
Jonathan Turkanis [EMAIL PROTECTED] writes:
I'm getting tired of this. You assumed I'm must have meant something
else than what I plainly asked; once I mentioned that I was writing a
book, you realized I really meant what I said.
That's pretty much it, yes.
Many years of experience have
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-09-21 06:51 ---
Subject: Re: x87 reg allocated for constants for -mfpmath=sse
Note that in this pattern cost computation of MMX_REGS are all ignored ('*'
in front of y). So, the cost
which is computed is
DCE (.t44.dce3) eliminates the third loop in the testcase below, although the
print loop should be enough to keep it alive:
==
subroutine foo(a,b)
real a,b
type bzz
real d(100)
end type bzz
type (bzz) e
dimension a(100), b(100)
read *,x,y
a=log(x)--- loop 1
b=log(y)
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|NEW
Hi,
I am facing a problem while compiling following code with gcc.
When i compile ofstream with char, it compiles fine.
But it gives linking error with wchar_t.
I compile with command gcc test.cpp
Could someone please look into this and let me know if i need additional
library to compile with ?
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-09-21
09:55 ---
Proposed patch:
http://gcc.gnu.org/ml/java-patches/2005-q3/msg00401.html
--
What|Removed |Added
This patch:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01279.html
breaks ia64. I got
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/final.c: In function `get_attr_length':
/net/gnu-13/export/gnu/src/gcc/gcc/gcc/final.c:454: error: `insn_default_length'
undeclared (first use in this function)
/opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning:
`
__va__list' redefined
/usr/include/sys/stdsyms.h:422: warning: this is the location of the previous
de
finition
In file included from ../../CommonClasses-
C++/AIParser/../CommonHeader/StdHdr.h:
34,
--- Additional Comments From a_manish at yahoo dot com 2005-09-21 10:10
---
compilation output errors:
g++ test.cpp
Undefined first referenced
symbol in
--- Additional Comments From chris at bubblescope dot net 2005-09-21 10:13
---
Could you provide the output of g++ -v, and the operating system you are using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
--- Additional Comments From a_manish at yahoo dot com 2005-09-21 10:26
---
===
i am compiling on sol9 machine
g++ -v
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.9/3.3.2/specs
Configured with: ../configure
The compiler will give the compile-time error: invalid lvalue in unary ''
The following code not only shows the bug, but also the non-template based
implementation that runs and compiles perfectly. The two dimensional array is
essential to observe the problem. The template code will run and
--- Additional Comments From bdonner at physik dot tu-muenchen dot de
2005-09-21 10:41 ---
Created an attachment (id=9786)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9786action=view)
Code to reproduce the bug -- correct version
The inline posted version incorrectly shows the 1d
Fortran 2003 defines the PROTECTED attribute for variables in modules. Example:
---
MODULE temperature
REAL,PROTECTED :: temp
CONTAINS
SUBROUTINE set_temperature
temp = 0.0
END SUBROUTINE
END MODULE
use temperature
call set_temperature
print *, temp
temp =
--
What|Removed |Added
BugsThisDependsOn||23994
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
spr16hmf:spluser(568) ~/tmp
gcc -v -gnatv -c test_gcc_4_0_1.ads
Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: /usr/local/src/tmp/GCC/4.0/gcc-4.0.1/configure
--prefix=/usr/local/GCC/4.0/1 --enable-threads=posix
--enable-languages=c,ada,c++,f95,java,objc,treelang
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From chris at bubblescope dot net 2005-09-21 11:01
---
Hopefully someone with more Solaris knowledge than me may come along (the code
works fine on any
OSes I can get my hands on)
As a temporary fix, you might find putting template class
char_traitswchar_t;
--
What|Removed |Added
GCC target triplet||sparc-sun-solaris2.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23990
--
What|Removed |Added
Keywords||build
Target Milestone|--- |4.1.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
11:08 ---
2.95.3 is not really supported any more.
--
What|Removed |Added
GCC target triplet|
--- Additional Comments From a_manish at yahoo dot com 2005-09-21 11:21
---
Thanks for replying.
But additing Fwd declaration did not help.
I am still getting the errors :
+=
g++ wofstream.cpp
Undefined first referenced
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
11:24 ---
Confirmed, reduced testcase:
const int data[2][4] = {
{0, 1, 2, 3}
};
template typename T
void t(int k) {
int candidate = data[1][k];
}
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-21
11:26 ---
[in answer to pinskia, who added the keyword accepts-invalid]
Currently, gfortran doesn't accept this code:
$ gfortran -std=f2003 a.f90
In file a.f90:2
REAL,PROTECTED :: temp
1
Error: Syntax
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
11:28 ---
Confirmed, it is kinda of interesting that IA64 is one of the few targets which
does not have the length
attr (or have HAVE_ATTR_length defined).
The easy fix is the following:
int
get_attr_length (rtx
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
11:30 ---
This should be fixed by:
http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01294.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
11:32 ---
I got this wrong because I thought from comment one it was accepting the
attribute already but just
ignoring it.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
12:19 ---
I forgot to mention that this worked with 4.0.2 20050826 but failed with
4.0.2 20050915.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23993
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From dorit at il dot ibm dot com 2005-09-21 13:16
---
Indeed. This bug can be closed now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
13:17 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Additional Comments From pcarlini at suse dot de 2005-09-21 13:27
---
I'm afraid this is a WONTFIX for gcc3.3.x, which is not maintained anymore. Can
you try a more recent release, like the forthcoming gcc4.0.2? According to the
audit trail of libstdc++/6702, the issue has been
DCE (.t44.dce3) eliminates the third loop in the testcase below, although the
print loop should be enough to keep it alive:
==
subroutine foo(a,b)
real a,b
type bzz
real d(100)
end type bzz
type (bzz) e
dimension a(100), b(100)
read *,x,y
a=log(x)--- loop 1
b=log(y)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21
13:34 ---
Subject: Bug 21418
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-21 13:34:29
Modified files:
gcc/java : ChangeLog class.c
Log message:
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-09-21
13:41 ---
This is wrong.
As I stated on IRC, that only fixes the problem as a side effect. There is a
real latent bug here. We should be getting the right result regardless of
whether points-to says it points to e
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21
13:45 ---
Subject: Bug 23891
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-21 13:45:22
Modified files:
libjava: ChangeLog
--- Additional Comments From dorit at il dot ibm dot com 2005-09-21 13:46
---
I don't know how this happened - I didn't mean to open this PR again. This
should be closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23997
On Sep 21, 2005, at 9:46 AM, dorit at il dot ibm dot com wrote:
--- Additional Comments From dorit at il dot ibm dot com
2005-09-21 13:46 ---
I don't know how this happened - I didn't mean to open this PR again.
This
should be closed.
Daniel opened because there is a latent bug
--- Additional Comments From pinskia at physics dot uc dot edu 2005-09-21
13:51 ---
Subject: Re: DCE removes a loop when it shouldn't
On Sep 21, 2005, at 9:46 AM, dorit at il dot ibm dot com wrote:
--- Additional Comments From dorit at il dot ibm dot com
2005-09-21 13:46
--
What|Removed |Added
OtherBugsDependingO||18131
nThis||
Target Milestone|--- |4.1.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
14:05 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--
Bug 18131 depends on bug 21418, which changed state.
Bug 21418 Summary: Order of source files matters when compiling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21418
What|Old Value |New Value
--- Additional Comments From joern dot rennecke at st dot com 2005-09-21
14:07 ---
Subject: Re: [4.1 Regression]: Gcc failed to build on ia64
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
11:28 ---
Confirmed, it
--
What|Removed |Added
Severity|critical|normal
Keywords||ice-on-valid-code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
14:12 ---
Can you attach the preprocessed source?
But from the looks of it, this is a bug in the headers of HPUX.
Also can you try a newer GCC since 2.95.3 is 4 years old.
--
What|Removed
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-21
14:18 ---
We insert the reciprocal computation correctly after the call to
double prrs = potentially_runnable_resource_share();
but as this call may trap and is the last instruction in the basic block,
inserting
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
14:23 ---
Oh, this is a dup. I missed the bug number change.
*** This bug has been marked as a duplicate of 23989 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
14:23 ---
*** Bug 23997 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
--
What|Removed |Added
Target Milestone|4.1.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23989
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-21
14:29 ---
I had to make the methods in B and C public in order
to compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23620
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
14:32 ---
: Search converges between 2004-08-30-trunk (#529) and 2004-08-31-trunk (#530).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23984
--- Additional Comments From paolo dot bonzini at lu dot unisi dot ch
2005-09-21 14:33 ---
Subject: Re: [4.1 Regression] internal compiler
error: verify_stmts failed
rguenth at gcc dot gnu dot org wrote:
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-21
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-21
14:44 ---
Fixing like the following, but inserting onto the right edge(s) -
single_succ_edge actually doesn't work here.
diff -c -3 -p -r2.5 tree-ssa-math-opts.c
*** tree-ssa-math-opts.c9 Aug 2005 03:28:32
--- Additional Comments From steven at gcc dot gnu dot org 2005-09-21
15:02 ---
Let's fix this.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21
15:08 ---
Subject: Bug 17609
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-09-21 15:08:00
Modified files:
gcc/cp :
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-21
15:12 ---
This is now fixed in GCC 3.4.5.
The new testcase g++.dg/lookup/error1.C will be added to mainline
and the 4.0 branch. In the meantime I'll keep the PR open.
--
Inserting the following code into get_inner_reference before if (size_tree !=
0), causes bootstrap failures where DECL_SIZE is NULL but shouldn't be
gcc_assert (size_tree != 0 || (TREE_CODE (exp) != COMPONENT_REF TREE_CODE
(exp) != BIT_FIELD_REF));
--
Summary: DECL_SIZE set to
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21
15:21 ---
Subject: Bug 17609
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-21 15:21:00
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-21
15:23 ---
Testcase now also in mainline.
Waiting for 4.0 branch to unfreeze.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17609
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21
15:34 ---
Subject: Bug 23965
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-09-21 15:34:42
Modified files:
gcc/cp : ChangeLog call.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-21
15:40 ---
Subject: Bug 23965
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-09-21 15:39:53
Modified files:
gcc/cp :
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-21
15:41 ---
Fixed on mainline and the 3.4 branch.
Waiting for 4.0 branch to unfreeze.
--
What|Removed |Added
vector constants are allocated in reversed order when building the test program
for a PowerPC little-endian executable.
Test case code, altivec_test.c
--
#include stdio.h
#if __GNUC__ = 3
#include altivec.h
#endif
int main(void)
{
#if __GNUC__ = 3
vector
For this code:
int f(int *ptr, int t) {
if (t)
return *ptr;
else
return *ptr;
}
the jump is not eliminated:
f: beq $17,$L2
ldl $0,0($16)
ret
$L2:ldl $0,0($16)
ret
This used to work with 2.95 (not sure whether that still counts as
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-21 16:09
---
I suspect this is an oversight from early patches of PR 17780. I'll look at
this.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23956
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-21 16:13
---
Paolo is right: wchar_t specializations are only supported on solaris starting
with gcc-3.4.0.
I would suggest using either
gcc-3.4.4
gcc-4.0.2
-benjamin
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-21
16:13 ---
Note most poeple don't use little endian PPC.
--
What|Removed |Added
Component|c
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-21 16:14
---
*** This bug has been marked as a duplicate of 6702 ***
--
What|Removed |Added
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-09-21 16:14
---
*** Bug 23990 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From xhliu at mc dot com 2005-09-21 16:22 ---
(In reply to comment #1)
Note most poeple don't use little endian PPC.
Yes, it is true. But Mercury supports little-endian PPC, and this is a bug in
GCC 3.x and 4.x.
--
1 - 100 of 139 matches
Mail list logo
