Hi,
i tried to compile gcc 4.1.0 (the final release) on windows, too. I'm using
msys and configured the buildprocess with --enable-threads=win32
--with-win32-nlsapi=unicode. On the msys console i type make and after a
while i get the error with the Makefile on line 1277. I make the fix and
[sorry for breaking the thread, stupid gmail interface doesn't allow
adding custom headers]
i tried to compile gcc 4.1.0 (the final release) on windows, too. I'm using
msys and configured the buildprocess with --enable-threads=win32
--with-win32-nlsapi=unicode. On the msys console i type make
I am not aware of any showstoppers for the 4.0.3 release.
Therefore, I plan to spin the release tomorrow evening, GMT - 8. Speak
now or forever hold your peace! :-)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Daniel Towner [EMAIL PROTECTED] writes:
Am I doing something fundamentally wrong with the way I am defining the
length attribute, or the delay slot attribute?
No, I think this just The Way Things Are. I had a similar problem
with the h8sx delayed branch, and ended up reversing the delay slot
Presumably there's a reason why enumeral types don't have a
base type?
They are viewed as full-blown types by Ada, forming the class of discrete
types with integral types, so there are probably no semantics reasons why
ENUMERAL_TYPE nodes should have an INTEGER_TYPE node as their base type.
They are viewed as full-blown types by Ada, forming the class of discrete
types with integral types, so there are probably no semantics reasons why
ENUMERAL_TYPE nodes should have an INTEGER_TYPE node as their base type.
I'll add here that at one point I tried doing it the above way
Recently, I'm very interested in the inlining model of gcc.I need a
detailed documentation describing how the inlining is implemented in
gcc 4.0. Anybody who has been or is working on it please send me a
documentation. I'd really appreciate your help.
There is no such documentation; you're
On Wed, 2006-03-08 at 12:36 +0100, Eric Botcazou wrote:
Presumably there's a reason why enumeral types don't have a
base type?
They are viewed as full-blown types by Ada, forming the class of discrete
types with integral types, so there are probably no semantics reasons why
One more note, we see the same kind of conditional and test
simplification with for cxa4028 in Ada.Strings.Superbounded.Super_Trim.
So I'm pretty confident that if we fix the bogus trees generated for
a-stwifi.adb that all three of these regressions will be fixed.
Confirmed.
--
Eric
While doing the memory SSA work, I started wondering about V_MUST_DEFs.
I think we don't need them anymore.
This may be a bit hasty on my part, I have not really thought it
through. But I cannot think of a single transformation that absolutely
*requires* V_MUST_DEFs to work.
When they were
On Wed, 2006-03-08 at 17:21 +0100, Eric Botcazou wrote:
One more note, we see the same kind of conditional and test
simplification with for cxa4028 in Ada.Strings.Superbounded.Super_Trim.
So I'm pretty confident that if we fix the bogus trees generated for
a-stwifi.adb that all three of
On 3/8/06, Diego Novillo [EMAIL PROTECTED] wrote:
While doing the memory SSA work, I started wondering about V_MUST_DEFs.
I think we don't need them anymore.
This may be a bit hasty on my part, I have not really thought it
through. But I cannot think of a single transformation that
On 03/08/06 11:54, Richard Guenther wrote:
i.e. we see that for a = b it's a killing def, while the assignment to
a.x[2] is only
partial. So what will we have in mem-ssa for the killing a = b and
the partial def?
Right now, nothing. Memory SSA gives you an identical IL in this case.
On 3/8/06, Diego Novillo [EMAIL PROTECTED] wrote:
On 03/08/06 11:54, Richard Guenther wrote:
i.e. we see that for a = b it's a killing def, while the assignment to
a.x[2] is only
partial. So what will we have in mem-ssa for the killing a = b and
the partial def?
Right now, nothing.
I started again (deleted the generated files) and configured with sh
../gcc-4.1.0/configure --prefix=/home/gcc41 --enable-threads=win32
--with-ld=/mingw/bin/ld --with-win32-nlsapi=unicode and fired make
bootstrap. I think this time make made more than the last time, but ejected
an error again
Hi Francois, Colm,
I've read your emails and I'd like to be involved in this project.
As you can read in my past emails in the GCC ML, I've tried two years ago to
create a porting of GCC to PIC 18FXXX.
The project was developed when I was student without a truly and strong guide
in all
see:
SDCC compiler for small devices.
http://sdcc.sourceforge.net/
This perhaps is a first point for begin this
Julian Niño
- Original Message -
From: Gabriele Caracausi [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 08, 2006 12:31 PM
Subject: RE: GCC Port (gcc backend)
I am interested by your work, you can share it. What was your Gcc
development version ?
Le mercredi 08 mars 2006 à 18:56 +0100, Gabriele Caracausi a écrit :
Hi Francois, Colm,
I've read your emails and I'd like to be involved in this project.
As you can read in my past emails in the GCC
Kindly post a solution to this prob:
http://gcc.gnu.org/ml/gcc/2003-10/msg01005.html
Solution is:
Copy the libiconv.so.2 file into /usr/lib
on your machine.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best
I notice in your PDF, you have:
Since alias analysis results are often conservative, may-alias sets my contain
tens
and enve hundreds of symbols.
Is there a reason why not tune the aliasing anaysis to return more liberal
results
instead of changing the representation?
From looking at Tramp3D,
On 03/08/06 15:05, Andrew Pinski wrote:
Is there a reason why not tune the aliasing anaysis to return more liberal
results
instead of changing the representation?
Yes, as I tried to explain on IRC, alias analysis is an undecidable
problem. It is impossible in general to compute an exact
Hi,
I am trying to build RTEMS tool RPMs from the vanilla
4.1.0 source. It dies trying to install a file into
a system directory. In the directory,
build/sparc-rtems4.7/soft/libssp it dies with:
test -z /opt/rtems-4.7/lib/gcc/sparc-rtems4.7/4.1.0/soft || mkdir -p
--
On 03/08/06 15:05, Andrew Pinski wrote:
Is there a reason why not tune the aliasing anaysis to return more liberal
results
instead of changing the representation?
Yes, as I tried to explain on IRC, alias analysis is an undecidable
problem. It is impossible in general to compute
Joel Sherrill [EMAIL PROTECTED] writes:
RPM invoked make install with the prefixes overriden:
make
prefix=/home/rtems/tmp/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.1.0newlib1.14.0-1-root-rtems/opt/rtems-4.7
Why don't you just set DESTDIR?
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL
I compiled gcc 3.4.5 on an i386 pc under Solaris 10 with posix threads.
When I try to compile certain downloaded tarballs (especially those that
use the gtk+ libs) gcc passes -mt to cc1, which chokes with an illegal
option error message. The gcc docs say that this option is for the IA64
on HPUX.
Andreas Schwab wrote:
Joel Sherrill [EMAIL PROTECTED] writes:
RPM invoked make install with the prefixes overriden:
make
prefix=/home/rtems/tmp/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.1.0newlib1.14.0-1-root-rtems/opt/rtems-4.7
Why don't you just set DESTDIR?
Wasn't needed
On Mar 8, 2006, at 2:27 PM, [EMAIL PROTECTED] wrote:
When I try to compile certain downloaded tarballs (especially those
that
use the gtk+ libs) gcc passes -mt to cc1, which chokes with an
illegal
option error message. The gcc docs say that this option is for
the IA64
on HPUX. What can
Rajkishore Barik wrote:
problems with the following instruction in post-reload.c:391 in
reload_cse_simplify_operands function stating that the insn does
not satisfy constraint.
There are lots of different ways that this problem can occur. It is
hard to say much without having a testcase I
Rogelio Serrano wrote:
When building gcc-4.1.0 with uclibc im getting and undefined
BITS_PER_UNIT error when building libgcc at the muldi3.
Using grep would show that it is defined in the defaults.h file. Using
grep again shows that defaults.h is supposed to be automatically
included in the
Tom Williams wrote:
I downloaded gcc-4.1.0 the other day and the compile went fine. When I
ran make check to make sure all went well, I get this error:
Always use make -k check. Otherwise, make will exit after the first
failure, instead of running all of the testsuites.
Some failures are
Zdenek Dvorak wrote:
*sched* -- no idea what happens there; it seems to make REG_SAVE_NOTE
notes from loop notes, and then makes some magic, but I do not
understand what and why.
The loop notes are converted into REG_NOTES, and attached to an adjacent
instruction. The REG_SAVE_NOTES are
Jim Wilson wrote:
Rogelio Serrano wrote:
When building gcc-4.1.0 with uclibc im getting and undefined
BITS_PER_UNIT error when building libgcc at the muldi3.
Using grep would show that it is defined in the defaults.h file.
Using grep again shows that defaults.h is supposed to be
Bernd Schmidt wrote:
Do we have a replacement for this heuristic?
I see REG_FREQ, which is computed from some basic block frequency info.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
I see that flow no longer uses loop_depth when computing REG_N_REFS,
That strikes me as wrong. Don't we want to give pseudos that are in loops
preference over those that aren't?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Incognito wrote:
I started again (deleted the generated files) and configured with sh
../gcc-4.1.0/configure --prefix=/home/gcc41 --enable-threads=win32
--with-ld=/mingw/bin/ld --with-win32-nlsapi=unicode and fired make
bootstrap. I think this
--- Comment #2 from emilp at mac dot com 2006-03-08 08:45 ---
But isn't this problem already solved for the using directive. The code below
compiles fine and works as expected. In fact, in the days of gcc 3, using
could be used for namespaces and behaved exactly the way I would prefer.
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:29
---
Confirmed on gcc mailing-list.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:51
---
This was fixed on rev. 110700 for trunk, and later backported to 4.1.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:55
---
(In reply to comment #23)
I think MIPS16, FRV and US_SOFTWARE_GOFAST still need fixing. (The last
quite likely by removing US_SOFTWARE_GOFAST support.)
Adding the maintainers of all those in Cc list. I
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-03-08 09:57
---
(In reply to comment #4)
Interesting darwin-fallback.c got the fix:
2005-03-25 Geoffrey Keating [EMAIL PROTECTED]
* config/rs6000/darwin-fallback.c: Don't include ucontext.h.
Use our own
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-08 10:18 ---
For mainline, this is a dup of 26449. For 4.1.0 I can reproduce this:
#1 0x08493eae in push_reload (in=0x4023a4b8, out=0x40241280,
inloc=0x40244a84, outloc=0x40229be0, class=NO_REGS, inmode=V4SImode,
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-08 10:40 ---
(gdb) call debug_rtx(*outloc)
(subreg:TI (reg:V4SI 23 xmm2 [99]) 0)
(but of course it looks like NO_REGS doesn't make any sense for this reload)
(gdb) up
#2 0x0849b343 in find_reloads (insn=0x402401b8, replace=0,
--- Comment #6 from rmathew at gcc dot gnu dot org 2006-03-08 11:40 ---
(In reply to comment #5)
Confirmed on gcc mailing-list.
Reconfirmed with the GCC 4.1.0 release tarballs for C (core)
and C++ (g++). In addition to using --with-ld, one has to
also use a relative path to the
when compiling
class A{
class B{}
}
class C extends A.B{}
with
gcj -S
compiler crashes
author of report
Marek Warpechowski [EMAIL PROTECTED]
--
Summary: compiler crashes segmentation fault
Product: gcc
Version: unknown
the code:
class A{
public:
A(int i){}
};
int main(){
A *a=new A[10](2);
int *p=new int[10](3);
}
--
2 problems:
1. This code compiles with g++ -Wall -ansi (no warning)
put I think that array initialisation is
forbidden in ANSI (the
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 12:39 ---
So it looks like this is HWI bug really, if a target needs to support TImode in
any shape or form, HWI should be set to 64bits no questions asked.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #3 from neil at fnxweb dot com 2006-03-08 12:41 ---
Was it compiled up to use mt_allocator? I won't have the time to check again
for a short while.
If it's considered a good idea to use -pthreads, then it ought really to have
it's info-page entry updated to not make it
--- Comment #6 from belyshev at depni dot sinp dot msu dot ru 2006-03-08
12:46 ---
This bug prevents emacs from working, it says M-x is undefined.
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 12:50 ---
This works for me by rejecting with -Wall -ansi:
pc64:~ ~/gcc-4.0/bin/gcc t2.cc -W -Wall -ansi
t2.cc:3: warning: unused parameter i
t2.cc: In function int main():
t2.cc:7: error: ISO C++ forbids initialization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 12:59 ---
This is invalid code as you cannot use A.B outside of A as it is not a static
inner class.
Confirmed, not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 13:00 ---
This is a dup of bug 18130.
*** This bug has been marked as a duplicate of 18130 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-08 13:00 ---
*** Bug 26603 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
EDG-based compilers accept (in strict mode) accept this:
templatetypename T
struct is_void
{ static const bool value = false; };
template
struct is_voidvoid
{ static const bool value = true; };
templatetypename, bool
struct enable_if { };
templatetypename T
struct enable_ifT, true
--- Comment #1 from pcarlini at suse dot de 2006-03-08 13:57 ---
Actually, the issue seems much simpler:
namespace one
{
templatetypename T
void
fun(T);
}
using one::fun;
templatetypename T
void
fun(T);
paolo:~/Work g++ -c reduced2.cc
reduced2.cc:12:
--- Comment #2 from pcarlini at suse dot de 2006-03-08 14:01 ---
Likely a duplicate of c++/21682, but simpler testcase ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 14:07 ---
(In reply to comment #2)
Likely a duplicate of c++/21682, but simpler testcase ;)
I don't know how that and comment #1 are valid code as in both cases the
arguments will be the same so you should get an error
--- Comment #4 from pcarlini at suse dot de 2006-03-08 14:11 ---
(In reply to comment #3)
(In reply to comment #2)
Likely a duplicate of c++/21682, but simpler testcase ;)
I don't know how that and comment #1 are valid code as in both cases the
arguments will be the same so you
--- Comment #5 from pcarlini at suse dot de 2006-03-08 14:15 ---
(In reply to comment #4)
I don't know how that and comment #1 are valid code as in both cases the
arguments will be the same so you should get an error about ambiguous
functions.
Not so early, I think, because T
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-08 14:21 ---
(In reply to comment #5)
And, by the way, this one already compiles:
But that names the same function, it is just like:
int f(void);
int f(void);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605
--- Comment #7 from pcarlini at suse dot de 2006-03-08 14:24 ---
(In reply to comment #6)
(In reply to comment #5)
And, by the way, this one already compiles:
But that names the same function, it is just like:
int f(void);
int f(void);
No, it's not the same, because we are
--- Comment #2 from aph at gcc dot gnu dot org 2006-03-08 14:35 ---
I've started some experimental work on this at
svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-abi-experimental-branch.
Initial improvements in grabage collection time are encouraging, but there are
some problems with
--- Comment #11 from greenrd at gcc dot gnu dot org 2006-03-08 14:39
---
Sorry, I can't submit patches to libjava because I'm tainted (except for the
packages that are new in Mustang, which I haven't seen). Even though this is a
small change, I prefer to err on the side of caution.
--- Comment #8 from pcarlini at suse dot de 2006-03-08 14:56 ---
(In reply to comment #7)
No, it's not the same, because we are dealing with the templates. I'm going to
study the standard (maybe you can also do that ;) but we have an hard fact:
both g++ and EDG accept the version
--- Comment #7 from bangerth at dealii dot org 2006-03-08 14:57 ---
(In reply to comment #6)
We don't use pre-compiled headers ourselves. Any precompiles are third-party
or
standard library, and actually I was unaware that they were used. Can you tell
me the files that the header
--- Comment #3 from bangerth at dealii dot org 2006-03-08 14:59 ---
I didn't make up the rules, so you're barking up the wrong tree :-)
But the difference between using directives for names and namespace
aliases is that a using directive is final: it imports a name into
the present
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-08 15:03 ---
Subject: Bug 24183
Author: tromey
Date: Wed Mar 8 15:03:48 2006
New Revision: 111844
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111844
Log:
PR libgcj/24183:
* native/jni/xmlj/Makefile.in:
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-08 15:05 ---
Fixed.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 15:11 ---
This turns out to be a dup of bug 25251 which was fixed for sure for 4.1.0.
*** This bug has been marked as a duplicate of 25251 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-08 15:11
---
*** Bug 20477 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-08 15:12 ---
Fixed for 4.1.0 for sure so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-08 15:13 ---
Any news on the testcase?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Last reconfirmed|2005-11-15 20:22:08 |2006-03-08
--
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=25440
--- Comment #5 from charlet at gcc dot gnu dot org 2006-03-08 15:16 ---
Nothing particularly critical in this PR, we've got plenty of other more
worrisome failures to look at.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-08 15:17 ---
Is there a testcase other than just compile and run nbench with
-ftree-loop-linear?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|--- |4.0.3
--- Comment #4 from emilp at mac dot com 2006-03-08 15:23 ---
I did come on a bit strong, didn't I? Sorry about that, I'm just a bit
frustrated since it used to work better in the gcc 3 series :-)
Do you have a suggestion as to where I could continue this discussion?
--
--- Comment #5 from bangerth at dealii dot org 2006-03-08 15:26 ---
(In reply to comment #4)
I did come on a bit strong, didn't I? Sorry about that, I'm just a bit
frustrated since it used to work better in the gcc 3 series :-)
Oh, don't worry. I put a smiley to my remark, just in
--- Comment #8 from charlet at gcc dot gnu dot org 2006-03-08 15:27 ---
Given that 4.1.0 has been released and issue is fixed there, closing this
PR.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from mikpe at csd dot uu dot se 2006-03-08 15:51 ---
I downloaded and installed cctools-590.12, and that did indeed solve the
gcc-4.1.0 bootstrap problem.
However, today I discovered that the newer cctools break gcc-3.4.x.
A zero-sized global variable, e.g. struct { }
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-08 15:52 ---
People have bootstraped and tested on AIX 5.3 without any troubles before and
after this patch has been filed?
What command are you using to bootstrap GCC?
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 15:57 ---
(In reply to comment #2)
However, today I discovered that the newer cctools break gcc-3.4.x.
A zero-sized global variable, e.g. struct { } unused;, gets translated
into a .comm _unused,1 by gcc-4, but gcc-3.4
--
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=25815
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P5
Target Milestone|--- |4.1.1
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-08 16:06 ---
Fixed in 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pcarlini at suse dot de 2006-03-08 16:08 ---
Hardly a regression, considering that ext/pb_assoc has been released for the
first time in 4.1.0 ;)
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from bonzini at gnu dot org 2006-03-08 16:11 ---
patch committed
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from bonzini at gnu dot org 2006-03-08 16:10 ---
Subject: Bug 26500
Author: bonzini
Date: Wed Mar 8 16:10:44 2006
New Revision: 111845
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111845
Log:
2006-03-08 Paolo Bonzini [EMAIL PROTECTED]
PR
--- Comment #9 from pcarlini at suse dot de 2006-03-08 16:20 ---
The below also works already (can make for an useful if ugly workaround, in
some cases, e.g., c++/21682):
namespace one
{
templatetypename T
void
fun(T);
}
namespace two
{
templatetypename T
void
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-08 16:25 ---
All 3.4.0 accept the code. Fixed with the new C++ parser.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-08 16:30 ---
Isn't this fixed in 4.1?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from allali at univ-mlv dot fr 2006-03-08 16:30 ---
(In reply to comment #2)
All 3.4.0 accept the code. Fixed with the new C++ parser.
I've checked and you're right. Is there a way to have array elements
initialized by a specific constructor in g++ 3.4 (to get the
--
gbenson at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |gbenson at redhat dot com
|dot org
--- Comment #3 from gbenson at redhat dot com 2006-03-08 16:32 ---
See http://people.redhat.com/gbenson/throwpoint-report.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21891
--- Comment #16 from law at redhat dot com 2006-03-08 16:43 ---
C++ version of the problems in 26344. Fixing 26344 will fix this bug as well.
*** This bug has been marked as a duplicate of 26344 ***
--
law at redhat dot com changed:
What|Removed
--- Comment #12 from law at redhat dot com 2006-03-08 16:43 ---
*** Bug 26406 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
--- Comment #6 from emilp at mac dot com 2006-03-08 16:47 ---
I'm considering filing a defect report (for a standard clarification) to the
commitee but I would like to make sure I'm not climbing any trees here... In
your first reply you said My understanding is that this code is in fact
--- Comment #7 from bangerth at dealii dot org 2006-03-08 17:21 ---
(In reply to comment #6)
I'm considering filing a defect report (for a standard clarification) to the
commitee but I would like to make sure I'm not climbing any trees here... In
your first reply you said My
1 - 100 of 170 matches
Mail list logo