Ian Lance Taylor ian@airs.com writes:
Richard Sandiford [EMAIL PROTECTED] writes:
Huh. For the record: it can't. get_attr_length() returns 0
for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'll update
the comment when applying the bug-fix patch to mainline.
shorten_branches handles
[EMAIL PROTECTED] wrote:
Attached are the patches for coldfire v4e. These
changes are originally contributed by Peter Barada. I
have migrated and tested these changes from gcc 3.04
to gcc 3.4 and now to mainline.
Thank you for submitting this patch. I've not yet
had the time to perform a
Zack Weinberg wrote:
Dave Korn [EMAIL PROTECTED] writes:
No write perms mate! However I'll check out HEAD and do a
before-and-after testsuite run overnight, and get back to you in the morning
with the results (UK time). Will --enable-languages=c,c++ be enough, or
do you want me to test
[EMAIL PROTECTED] wrote:
- You don't seem to consistently patch both
MOTOROLA and !MOTOROLA paths.
Is this intentional? AFAIK, there are no
ColdFire targets using the MIT syntax,
but we need to be consistent;
I think it is only for the new patterns that these
paths are not followed. Do
On Tue, 12 Apr 2005 10:59:42 -0700, Mark Mitchell [EMAIL PROTECTED] wrote:
Sadly, it's become clear there's going to have to be a second release
candidate. In particular, there are some wrong-code bugs that are popping
up on real packages on primary platforms. Jason Merill is looking into
On Apr 13, 2005, at 1:41 AM, Ranjit Mathew wrote:
Exception in thread main java.lang.RuntimeException: test failed:5
No stacktrace available
FAIL: Array_3 -O3 execution - bytecode-native test
This one is expected I think, though not XFAILed (it
fails only at -O3).
BTW, you keep getting No
On Tue, Apr 12, 2005 at 10:59:42AM -0700, Mark Mitchell wrote:
I don't have a date for RC2 yet; that will depend in part on when Jason
is able to fix the C++ issues. However, I would certainly hope that we
could get it done shortly.
FYI, I have bootstrapped/regtested 4.0 RC1 with:
Here
Hi,
We have this charming move_insn function in haifa-sched.c:
/* Move INSN. Reemit notes if needed.
Return the last insn emitted by the scheduler, which is the
return value from the first call to reemit_notes. */
static rtx
move_insn (rtx insn, rtx last)
{
rtx retval = NULL;
Georg Steffers writes:
Hi,
i am working on a lib that should implement OO methods in C. I tried to
build up an exception system using longjmp and ran into a problem. I am
searching for an answer a month now and am actually not bit farther
than at the beginning. Actually i am not
Andrew Haley writes:
Eric Botcazou writes:
which I see you've already committed a patch for, and a large number
of Java failures.
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00814.html
for 4.0.0-20050410.
Same failure as on Solaris.
Andrew, do
Steven Bosscher wrote:
Hi,
We have this charming move_insn function in haifa-sched.c:
/* Move INSN. Reemit notes if needed.
Return the last insn emitted by the scheduler, which is the
return value from the first call to reemit_notes. */
static rtx
move_insn (rtx insn, rtx last)
{
rtx retval
My Darwin build of 4.0 failed in libstdc++:
ibsupc++convenience.a -lm -lm -lc -Wl,-single_module -Wl,-flat_namespace
-install_name /Users/aph/gcc/install/lib/libstdc++.6.dylib
-compatibility_version 7 -current_version 7.4
ld: .libs/mt_allocator.o malformed object, illegal reference for
Richard Sandiford [EMAIL PROTECTED] writes:
Ian Lance Taylor ian@airs.com writes:
Richard Sandiford [EMAIL PROTECTED] writes:
Huh. For the record: it can't. get_attr_length() returns 0
for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'll update
the comment when applying the bug-fix
On Apr 13, 2005, at 10:06 AM, Chris Kirby wrote:
We are trying to use -finstrument-functions to do some custom
profiling on x86 and ppc.
For normal code execution, it works fine, calling our entry and exit
methods as expected.
Unfortunately, we are running into problems related to exceptions.
On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
When we have a test block gating whether a loop should be
entered, the new block frequency check causes the code to pick the non-loop
path as the next block to add to the trace since the loop header block has
a higher frequency, and hence the
Vishal Kothari wrote:
Hi,
Can someone tell me how do I use GCC to build for ARM target?
See Dan Kegel's crosstool:
http://kegel.com/crosstool/
And questions regarding building cross-toolchains are better off posted
on the crossgcc list:
http://sources.redhat.com/ml/crossgcc/
Eric
On Wed, Apr 13, 2005 at 10:10:39AM +0200, Bernardo Innocenti wrote:
What are the changes you need to apply?
Would plain 68020 code run on v4e processor? As far
as I can see, m68k-linux isn't a multilib target.
Problem occurs mainly due to restricted addressing
modes in v4e. For ex
Hi. I just sent you two e-mails in which I said James Blair recommended that I
do so. I'm forwarding this response to you to clarify that the recommendation
came to me from someone who was acting on behalf of James Blair.
Thanks,
Chris Miller
LynuxWorks Tech Pubs
-Original Message-
Hi. Here's the second e-mail my previous message referred to. As that
e-mail explained, I'd sent my questions originally to [EMAIL PROTECTED],
thinking that that person would be the best one to answer questions about
GNU mailing lists, but James Blair responded by recommending that I look at
the
Thanks. I was under the impression that 2.4 doesn't build with GCC
HEAD, anyway - I saw some patches pile up and not get applied.
AFAIK some gcc 4.0 patches went in. I assume it will build eventually
at least once 4.0 is released.
Does 2.6 still use the option?
No.
However the change
Steven Bosscher [EMAIL PROTECTED] wrote on 04/13/2005 09:39:55 AM:
On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
When we have a test block gating whether a loop should be
entered, the new block frequency check causes the code to pick the
non-loop
path as the next block to add to
On Wednesday 13 April 2005 20:46, Pat Haugen wrote:
Steven Bosscher [EMAIL PROTECTED] wrote on 04/13/2005 09:39:55 AM:
On Wednesday 13 April 2005 00:18, Pat Haugen wrote:
When we have a test block gating whether a loop should be
entered, the new block frequency check causes the code to
On Wednesday 13 April 2005 21:19, Roger Sayle wrote:
A slightly better approach would be to include the dejagnu
testsuite in the coverage analysis, as the preferred policy of
adding a new testcase to trigger each transformation/optimization
might help here.
We can do that kind of testing (I
Chris Miller wrote:
Hi. I'm hoping you can help me with the questions in this e-mail and the
one that follows.
Bugs should be reported into bugzilla. Period. The old info is
obsolete and should be ignored. See
http://gcc.gnu.org/bugs.html
Mailing list info can be found here:
gcc/doc/install.texi still mentions gcc 3.5 in a few places.
paul
On Wednesday 13 April 2005 22:52, Pat Haugen wrote:
Back to the original problem with the algorithm using edge frequency vs.
block frequency. Would you agree that the correct thing to do is fix the
code so that it uses block frequency, especially since the patch of
Zdenek's you referenced
On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote:
Not necessary. If people would simply follow the directions here:
http://gcc.gnu.org/install/specific.html#*-*-solaris2* by setting
Also, when I click on the link above, it doesn't follow down the page
to the anchor. I'm not sure why that is.
I'm afraid we'll have to rename all of these in some way, either by
replacing * by x or by prepending some string. I'm not too fond
of either, but just using x instead * might be less ugly.
Somewhat.
What do you think?
Gerald
I like prepending a string, for example target= or
Eric Ugh. Not very surprising, given that a jumbo patch landed by
Eric that time:
Did this get resolved?
Eric Tom, I presume there was a very good reason for installing such
Eric a potentially destabilizing patch a few days before the
Eric prerelease? What amount of testing did it undergo
Gerald Pfeifer wrote:
On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote:
Not necessary. If people would simply follow the directions here:
http://gcc.gnu.org/install/specific.html#*-*-solaris2* by setting
Also, when I click on the link above, it doesn't follow down the page
to the anchor. I'm not sure
On Apr 13, 2005, at 1:30 AM, thanh tuan wrote:
I am a student, and I am studying to build an ANSI C compiler into
ASM.
I know, you can download gcc and then do configure make CFLAGS=-
save-temps. This will give you asm for an ANSI C compiler. :-)
[ wrong list, please use gcc-help instead. ]
Hi,
On Wed, 13 Apr 2005, Nick Rasmussen wrote:
I'm running into an ICE in the prerelease, that is proving to be
very difficult in reducing to a small testcase. If I preprocess
the source (via -E or -save-temps) the code successfully compiles.
If I minimally change the source file in some
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-04-13 06:06
---
Janis, can we close this out please?
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20694
--- Additional Comments From mendola at bigfoot dot com 2005-04-13 06:07
---
(In reply to comment #2)
(In reply to comment #1)
The code is invalid:
t.cc: In instantiation of S TestS::myS:
t.cc:32: instantiated from static void TestT::out() [with T = S]
t.cc:40:
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-13
06:28 ---
Maybe 4.0 with the patch for PR20929 triggers the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20963
--- Additional Comments From laurent at guerby dot net 2005-04-13 06:48
---
Arnaud, may be a candidate for review?
--
What|Removed |Added
CC|
it is fortran 77 code, if it is irrelevant please tell me. if you are interested
i have other bugs.
/home/antoine/bin/gfortran -v
Utilisation des specs internes.
Target: x86_64-unknown-linux-gnu
Configuré avec: ../gcc-4.0-20050402/configure --prefix=/home/antoine
--with-gmp=/home/antoine/
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-13
08:27 ---
Fixed in 4.1, waiting for 4.0 to reopen to apply there.
--
What|Removed |Added
--- Additional Comments From charlet at adacore dot com 2005-04-13 08:32
---
Subject: Re: makeinfo cannot process gnat_ugn_unw.texi
Arnaud, may be a candidate for review?
Sure. I'd suggest posting the patch to gcc-patches@
Arno
--
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-13
09:23 ---
Paolo Bozini mentioned this bug as an example of the 64bits arith
on 32bits host issue.
--
What|Removed |Added
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-13
09:34 ---
Fixed in 4.1, waiting for 4.0.1 to reopen.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
09:39 ---
But the code is still invalid and is really a dup of bug 20133.
You most want:
template class T int TestT::myInt;
template class T S TestT::myS = S::instance();
Not what you gave.
The orginal ICE is fixed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
09:46 ---
956.4byte $LFB4-.
Are you sure that this is not an assembler problem?
--
What|Removed |Added
--- Additional Comments From jakub at redhat dot com 2005-04-13 09:46
---
Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null
on entry
On Tue, Apr 12, 2005 at 05:54:58PM -, mmitchel at gcc dot gnu dot org wrote:
--- Additional Comments From
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
09:58 ---
Fixed in 3.4.0 and above:
t.cc: In static member function `static int S::f4()':
t.cc:13: error: `int S::C::i' is private
t.cc:19: error: within this context
--
What|Removed
--- Additional Comments From uros at kss-loka dot si 2005-04-13 09:58
---
(In reply to comment #7)
Uros, what's the state of this bug? I don't understand if the patch linked in
comment #6 was committed, or which is its final version still pending
review/approval.
Another approach
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-04-13
10:01 ---
The program test_spread from the original bug report
is bogus. dim=1000 doesn't make sense (which invalidates
my comment #5 and makes this particular case a diagnostics
issue).
Thomas
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
10:03 ---
Even though this is a dup of bug 20971 which was just reported yesterday,
please report more bugs.
There are a large number of bugs in gfortran which are not known yet.
*** This bug has been marked as a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
10:03 ---
*** Bug 20986 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
10:03 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From bernds_cb1 at t-online dot de 2005-04-13
10:08 ---
Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes
one argument null on entry
Jakub Jelinek wrote:
PR target/20126
* loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed,
gdc -v --save-temps -c VincoloIIF.d
-- BEGIN OF OUTPUT --
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr --exec-
prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --
mandir=/usr/share/man
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
10:51 ---
Since the D front-end is not part of GCC, we cannot reproduce you bug. I would
report this bug to the
people you got the D front-end from.
--
What|Removed |Added
--- Additional Comments From jakub at redhat dot com 2005-04-13 11:38
---
Subject: Re: [3.3/3.4/4.0 Regression] Inlined memcmp makes one argument null
on entry
On Wed, Apr 13, 2005 at 12:05:35PM +0200, Bernd Schmidt wrote:
Jakub Jelinek wrote:
PR target/20126
* loop.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-13
12:01 ---
Subject: Bug 13744
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-13 12:01:03
Modified files:
gcc/testsuite : ChangeLog
Added files:
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-13
12:07 ---
Fixed on mainline (which will become 4.1.0).
--
What|Removed |Added
--
Bug 18378 depends on bug 13744, which changed state.
Bug 13744 Summary: ICE when using implicit copy constructor for struct defined
in template function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13744
What|Old Value |New Value
--- Additional Comments From dhruvbird at yahoo dot com 2005-04-13 12:11
---
(In reply to comment #1)
Created an attachment (id=8615)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8615action=view)
free_list:: static removal
Hi,
What has been done seems ok, but there is just
The -M preprocessor option (and -MM and similar options) strips the directory
part from the listed object file names. The documentaion for -M says:
Unless specified explicitly (with `-MT' or `-MQ'), the object file
name consists of the basename of the source file with any suffix
replaced
On Tue, Apr 12, 2005 at 04:55:20PM -, law at redhat dot com wrote:
That mental model doesn't work right now with the way DOM the
jump threader because they are too tightly intertwined.
The link that you have still not shown me is why doesn't this
mental model work for the jump threader.
--- Additional Comments From dnovillo at redhat dot com 2005-04-13 13:03
---
Subject: Re: [4.0 Regression] jump threading on trees is slow with switch
statements with large # of cases
On Tue, Apr 12, 2005 at 04:55:20PM -, law at redhat dot com wrote:
That mental model doesn't
--- Additional Comments From dir at lanl dot gov 2005-04-13 13:08 ---
Here is the crash walk back
Thread 0 Crashed:
0 libgfortran.0.dylib 0x0023e99c _gfortran_compare_string + 0x68
(string_intrinsics.c:136)
1 adini 0x1d2c MAIN__ + 0x40 (adini.f:6)
/home/antoine/bin/gfortran -v
Utilisation des specs internes.
Target: x86_64-unknown-linux-gnu
Configuré avec: ../gcc-4.0-20050402/configure --prefix=/home/antoine
--with-gmp=/home/antoine/ --without-libiberty
Modèle de thread: posix
version gcc 4.0.0 20050402 (prerelease)
command line :
Current gcc-4_0-branch (i.e. with PR20635 fix in) ICEs on the attached testcase
at -O3 -m32. It is a recent regression (the assert was added 2005-03-18)
and prevents building Octave.
virtual std::string octave_value::class_name() const (this)
{
...
}
seen in *.generic dump seems to be unused
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-13 13:28
---
Created an attachment (id=8617)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8617action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
--- Additional Comments From neil at gcc dot gnu dot org 2005-04-13 13:29
---
Not a bug - you misunderstand basename.
--
What|Removed |Added
Status|UNCONFIRMED
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Summary|ICE in
g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-language=c,c++
--prefix=/home/dinar/work/gcc-builds/gcc-4.0-i686-pc-linux-gnu/
Thread model: posix
gcc version 4.0.0 20050412 (prerelease)
while compiling source code:
g++ sample.c -c
sample.c: In
--- Additional Comments From dtemirbulatov at ru dot mvista dot com
2005-04-13 13:36 ---
Created an attachment (id=8618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8618action=view)
source to compile
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20992
--- Additional Comments From bje at safepro dot dk 2005-04-13 13:43 ---
Then I suggest that the manual is clarified to make it clear what is meant.
The word basename is easy to misunderstand, especially because
the basename function in GNU make do keep the directory part
of its
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
13:44 ---
A(A) is a copy constructor but does not allow binding to a temporary variable
which is required here
even if it is not called.
--
What|Removed |Added
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-13 14:26
---
Somewhat simplified testcase:
#include vector
#include string
struct A { int i; };
struct B { int i; };
struct C { int i; };
struct D { int i; };
struct E
{
E (void);
E (bool b);
E (const A m);
--- Additional Comments From bje at safepro dot dk 2005-04-13 14:38 ---
Actually the manual explicit says that any path in the input file name is kept
by default in the description of the -MT TARGET option. So either the
preprocessor or the manual does have a bug when the preprocessor
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-13 14:56
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01456.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20702
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-13 14:56
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01457.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20913
--
What|Removed |Added
CC||dmitri at unm dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20991
The following code will not link because j.getName has multiple definitions.
Both j.o and natj.o contain a T definition when natj.o should contain a W def.
Ultimatly this causes the mingw 4.0.0 cross compiler to not build a functioning
native compiler becuase libgcj.a contains multiple
The following code snippet casues an ICE on mainline when compiled with
-O -ftree-vectorize. The 4.0 branch is not affected.
===
int foo(double* p)
{
int i=0;
for (double* q; q!=p; ++q)
if (*q)
++i;
return i;
}
This little piece of code here
-
template int dim
void test ()
{
double d;
double mu = 1;
for (unsigned int i=0; idim; ++i)
for (unsigned int j=0; jdim; ++j)
for (unsigned int k=0; kdim; ++k)
for (unsigned int l=0; ldim; ++l)
d = (((i==k) (j==l) ?
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-13
15:29 ---
Subject: Bug 20913
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-13 15:28:55
Modified files:
gcc: ChangeLog tree-ssa-copy.c
--- Additional Comments From bangerth at dealii dot org 2005-04-13 15:29
---
Note that it isn't related to PR 19899, even though the failure seems similar.
I should also note that the ICE happened with a compiler that had checking
enabled.
If checking is disabled, we simply get this:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-13
15:33 ---
Subject: Bug 20913
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-13 15:33:18
Modified files:
gcc: ChangeLog tree-vrp.c
--- Additional Comments From ericw at evcohs dot com 2005-04-13 15:43
---
FYI, I've tested the patch on my system here and it works for me.
Eric
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20822
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-13
15:57 ---
Subject: Bug 20924
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-13 15:57:38
Modified files:
gcc: ChangeLog
gcc/config/ia64:
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-04-13
16:09 ---
The ICE was introduced with a merge from the tree-cleanup-branch:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00501.html
BTW, here's a C testcase:
===
int foo(double* p, double*
--- Additional Comments From janis at gcc dot gnu dot org 2005-04-13 16:54
---
This was fixed by a patch by Mark Mitchell on 2005-04-01.
--
What|Removed |Added
--- Additional Comments From dhruvbird at yahoo dot com 2005-04-13 16:56
---
(In reply to comment #19)
I want to emphasize here again one principle of C and C++: Trust the
programmers, and allow them to do low-level tunings for performance. Or what
is
the purpose of C++ (when
--- Additional Comments From mueller at kde dot org 2005-04-13 16:57
---
can we think about retargeting fixing the optimisation for 4.0.1 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
The code below won't compile. It behaves as though the line
class valT { friend class rec; } is erroneously declaring a 'struct rec' in
the global namespace. (Uncomment the other use of rec to see this.) The error
message from 4.0 is:
y.cpp: In function 'int main(int, char**)':
y.cpp:29: error:
--- Additional Comments From dhruvbird at yahoo dot com 2005-04-13 17:02
---
Subject: Re: __gnu_cxx::bitmap_allocator export pruning
--- bkoz at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Additional Comments From bkoz at gcc dot gnu
dot org 2005-04-13 16:32 ---
I
--- Additional Comments From law at redhat dot com 2005-04-13 17:11 ---
Subject: Re: [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases
On Wed, 2005-04-13 at 13:04 +, dnovillo at redhat dot com wrote:
--- Additional Comments
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
17:38 ---
Fixed on the mainline (for 4.1.0), there might be a dup of this bug somewhere
with the rest of the
friend bugs in GCC.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
17:39 ---
Fixed at least on the mainline.
--
What|Removed |Added
Summary|[4.0/4.1
--
What|Removed |Added
CC||dnovillo at gcc dot gnu dot
||org
Target Milestone|---
--
What|Removed |Added
Component|c++ |libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20993
When running gij with the -verbose option, it immediately fails with the
following error:
$ gij -verbose C1
libgcj: couldn't create virtual machine
Same for '-verbose:class', '--verbose', or any other verbose option.
Reproduced on 4.0.0 and HEAD.
--
Summary: gij -verbose fails with
--- Additional Comments From ziga dot mahkovec at klika dot si 2005-04-13
17:49 ---
Created an attachment (id=8619)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8619action=view)
Fix for the parsing code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20997
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-13
17:50 ---
It does not ICE with 3.4.0 20040116 but does with 3.4.0 (release).
--
What|Removed |Added
--- Additional Comments From drow at false dot org 2005-04-13 17:50 ---
Subject: Re: New: building mips/64 cross compiler on x86 produces incorrect
assembler code for _divdi3 with -fnon-call-exceptions
On Wed, Apr 13, 2005 at 05:22:07AM -, herbert at 13thfloor dot at wrote:
1 - 100 of 214 matches
Mail list logo
