On 2005-04-18, at 04:22, Dan Kegel wrote:
Once the gcc C++ ABI stabilizes,
i.e. once all the remaining C++ ABI compliance bugs have
been flushed out of gcc, this requirement can be relaxed.
Thus in esp. on Judgment Day we will relax this requirement.
The changes in CPU instrution sets surpasses
On Apr 18, 2005 07:41 AM, Roger Sayle [EMAIL PROTECTED] wrote:
On Sat, 16 Apr 2005, Richard Kenner wrote:
Although, RTL expansion may introduce new loops, these tend to be
rare, and the expanders have all the information they need to
hoist/sink invariant expressions and
Geoffrey Keating writes:
Andrew Haley [EMAIL PROTECTED] writes:
Ranjit Mathew writes:
Geoffrey Keating wrote:
[...]
which I see you've already committed a patch for, and a large number
of Java failures.
You can see full test results at
[...]
I take it from your comments, that you are in the camp that believes
that the sun has not yet set on the need for RTL optimizers. :-)
I'm actually in the camp that the sun will never set on the need for
some RTL optimizers. We'll be able to remove some of the most costly
of them and the
How does the i386 backend optimise the stack slot assignment to minimize
the displacement offset?
What code should I look at?
Or is there some other optimisation at work here...?
I.e.:
; -O0 = large offset
leal8268(%esp), %eax
incl(%eax)
; -O3 = small offset
Unfortunately you appear to have little clue what you are really
talking about. So let me provide you with some loud feedback as well.
Please try to keep this discussion on a civil level!
I had greatly underestimated the importance of RTL alias analysis,
especially with
After encountering problems with 3.4.3 of gcc (it did not compile a
package I really needed to have - yes yes I am sure it is right and
better, BUT ...), I went back to 3.3.3 for a while. I just noticed that
there are two copies of libraries installed the install script on my
machine (one in
What is the purpose of having two such identically names libraries?
To support 2 architectures, 32-bit (sparcv7) and 64-bit (sparcv9).
Or alternatively - which is the real one that I should be using?
Both, but the compiler automatically picks up the right one, depending on
whether you
On Apr 18, 2005 02:51 PM, Richard Kenner [EMAIL PROTECTED] wrote:
Unfortunately you appear to have little clue what you are really
talking about. So let me provide you with some loud feedback as well.
Please try to keep this discussion on a civil level!
I am (for a change, maybe)
Hi folks.
All mail addressed to me from Apr-3 to Apr-10 was not delivered. I was
having problems with my mail setup. Please resend.
My apologies for reporting this so late; I've been sequestered at
customer sites with no internet for the past week after my vacation :-(.
Cheers.
Aldy
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results with the
contrib/test_summary script, and send me a message saying whether or
not there are
Please try to keep this discussion on a civil level!
I am (for a change, maybe) not the one who started making the
discussion uncivil.
I'm sorry, but in my opinion that doesn't matter. I don't call people
names or make personal attacks no matter what I'm responding to.
This
Well, paradoxical subregs are just a mess:
Agreed, but I wasn't talking about the paradoxical case.
optimizations on paradoxical subregs are better served at the tree
level, because it is just obfuscation of e.g. QImode arithmetic.
Not clear: I think this is a more complex issue.
On 2005-04-17 19:34:40 -0700, Brooks Moses wrote:
Yes, the standard refers to changing the rounding mode if the processor
supports [it] -- but consider what the standard means by processor:
The combination of a computing system and the means by which programs
are transformed for use on that
On Mon, 18 Apr 2005, Paolo Bonzini wrote:
Roger proposed lowering 64-bit arithmetic to 32-bit in tree-ssa! How
would you do it? Take
long long a, b, c;
c = a + b;
Would it be
c = ((int)a + (int)b)
+ ((int) (a 32) + (int) (b 32)
+ ((unsigned int)
But it turned out that CSE around basic blocks (-fcse-skip-blocks) was
still a very useful thing to do (and it still was, when I looked at it
again a couple of weeks ago).
And I would *very much* like to know why! My view was always that any
global CSE at all should render it unnecessary
On Apr 18, 2005, at 8:35 AM, Daniel Jacobowitz wrote:
Hi Caroline,
You've made this change to assemble_start_function (unidiff format):
+ last_text_section = no_section;
+ in_section = no_section;
resolve_unique_section (decl, 0, flag_function_sections);
+
+ /* Switch to the correct text
From line_map comment at (libcpp/include/line-map.h)
/* Physical source file TO_FILE at line TO_LINE at column 0 is
represented
by the logical START_LOCATION. TO_LINE+L at column C is
represented by
START_LOCATION+(L*(1column_bits))+C, as long as C
(1column_bits),
What happens when
On Mon, Apr 18, 2005 at 09:47:55AM -0700, Caroline Tice wrote:
Just out of curiousity, could you be more explicit about exactly how
having
an extra .text breaks the mechanism? That worries me...
asm(.section .init);
void _init() {
asm(@@@ MARKER @@@);
}
Then sed is used to separate the
Hi,
thanks for your responses.
I've debugged a little further and found out that
the testcase breakage was caused by (the elfos.h part):
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00913.html
The elfos.h part of the patch was reverted on 04/14/2005:
You seem to be confused. We've known *why* CSE does stuff that GCSE
doesn't catch for almost as long as we've had GCSE.
It's because CSE *doesn't just do CSE*! It does value numbering, and
a bunch of other things, which are not really implemented at the RTL
level as seperate
I am trying to comment out
static GTY (()) int foo = 0;
with
#if 0
static GTY (()) int foo = 0;
#endif
But I got an error saying something like
./gth:44: error: foo undeclared here (not in a function)
Is that expected? How can I comment it out?
H.J.
On Apr 18, 2005, at 2:11 PM, H. J. Lu wrote:
I am trying to comment out
static GTY (()) int foo = 0;
with
#if 0
static GTY (()) int foo = 0;
#endif
But I got an error saying something like
./gth:44: error: foo undeclared here (not in a function)
Is that expected? How can I comment it out?
Yes,
Answer: FRAME_GROWS_DOWNWARD.
The stack slots for the registers spilled on the
stack are allocated last. When the frame grows downward,
the displacement is smaller than if the frame grows upward.
Thanks.
--
Øyvind Harboe
http://www.zylin.com
Hi,
I've been looking at GCC's use of sign-extensions when dealing with
integers smaller than a machine word size. It looks like there is room
for improvement.
Consider this C function:
short g(short x)
{
short i;
for (i = 0; i 10; i++) {
x += i;
}
On Apr 18, 2005, at 9:55 AM, Devang Patel wrote:
From line_map comment at (libcpp/include/line-map.h)
/* Physical source file TO_FILE at line TO_LINE at column 0 is
represented
by the logical START_LOCATION. TO_LINE+L at column C is
represented by
START_LOCATION+(L*(1column_bits))+C, as
On Monday 18 April 2005 18:28, Daniel Berlin wrote:
The correct viewpoint is we shouldn't remove CSE until every *profitable*
transformation it makes is subsumed by something else.
Otherwise, you've started with the unproven assumption that every
transformation CSE makes is profitable.
Well,
On Monday 18 April 2005 20:53, Nicholas Nethercote wrote:
Hi,
I've been looking at GCC's use of sign-extensions when dealing with
integers smaller than a machine word size. It looks like there is room
for improvement.
Is your problem the same as the one described on one of the Wiki pages,
On Mon, Apr 18, 2005 at 07:44:03AM -0700, Mark Mitchell wrote:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results with the
c,ada are clean on x86 and x86_64 linux.
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01311.html
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01313.html
Laurent
was: Re: *SPAM* Re: My opinions on tree-level and RTL-level
optimization
On Monday 18 April 2005 19:43, Richard Kenner wrote:
an email.
Which the Novell spam filter thinks is spam.
Sorry if I miss an email from you, the reason is obvious: I throw
all messages marked SPAM straight to
On Mon, 2005-04-18 at 13:34 -0700, Dan Nicolaescu wrote:
[EMAIL PROTECTED] (Richard Kenner) writes:
The correct viewpoint is we shouldn't remove CSE until every
*profitable* transformation it makes is subsumed by something else.
And, as I understand it, the claim is that
Hi Richard,
The documentation for the atomic operation patterns says things like:
This pattern must issue any memory barrier instructions such that the
pattern as a whole acts as a full barrier.
Should the barrier happen before the operation, after the operation,
are there two barriers, or is it
Steven Bosscher [EMAIL PROTECTED] writes:
was: Re: *SPAM* Re: My opinions on tree-level and RTL-level
optimization
On Monday 18 April 2005 19:43, Richard Kenner wrote:
an email.
Which the Novell spam filter thinks is spam.
This is because he is using an obsolete mailer that
Ken Raeburn wrote:
On Apr 16, 2005, at 15:45, Nathan Sidwell wrote:
It's not clear to me which is the best approach. (b) allows threads to
be supported via copious uses of volatile (but probably introduces
pessimizations), whereas (a) forces the thread interactions to be
compiler
visible (but
On 2005-04-18, Mark Mitchell [EMAIL PROTECTED] wrote:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results with the
contrib/test_summary
Björn Haase wrote:
In case that one should not use machine specific atttributes, *is* there a
standard way for GCC how to implement different address spaces?
Use section attributes to force functions/variables into different
sections, and then use linker scripts to place different sections into
On Apr 18, 2005, at 3:08 PM, Ken Raeburn wrote:
Is there anything in the language specifications (mainly C++ in
this context, but is this an area where C and C++ are going to
diverge, or is C likely to follow suit?) that prohibits spurious
writes to a location?
No, in both languages. The
H. J. Lu [EMAIL PROTECTED] writes:
I am trying to comment out
static GTY (()) int foo = 0;
with
#if 0
static GTY (()) int foo = 0;
#endif
But I got an error saying something like
./gth:44: error: foo undeclared here (not in a function)
Is that expected? How can I comment
Joe For sparc-sun-solaris2.8, I get a failure when building the Java
compiler,
Joe but I may be doing something wrong, as I usually avoid the Java build
Joe on Solaris (since it takes most of a day to build and test). The message
Joe is
Joe java/parse.o(.text+0x16cc): In function
James Tabor wrote:
fp-bit.c:744: error: unrecognizable insn:
(call_insn:HI 53 49 59 0 fp-bit.c:743 (parallel [
(set (reg:SF 33 1)
(call (mem:SI (symbol_ref:SI (__pack_f) [flags 0x41]
function_decl 0xb7de7e0c __pack_f) [0 S4 A32])
(const_int 0
Clemens Koller wrote:
/usr/local/lib/nof/libstdc++.so.6: undefined reference to
[EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to
[EMAIL PROTECTED]'
These functions should come from libgcc_s.so or libgcc_eh.a, depending
on whether this is a shared or static link.
Try
Petar Penchev wrote:
I tried to use force_reg or PUT_MODE
but it does nothing and PUSH AL, inc S remain.
If nothing is happening, then that means the peephole isn't matching.
The matching happens in peephole2_insns. You could try putting a
breakpoint there and stepping through the code to see
Guochun Shi wrote:
make[1]: Entering directory
`/home/gshi/gcc/gcc-4.0.0-20050410/build-i686-pc-linux-gnu/libiberty'
make[1]: *** No rule to make target `../include/ansidecl.h', needed by
`regex.o'. Stop.
make[1]: Leaving directory
Ling-hua Tseng wrote:
It's obvious that `movil' and `movim' are only access the partial
16-bit of the 32-bit register. How can I use RTL expression to
represent the operations?
As you noticed, within a register, subreg can only be used for low
parts. You can't ask for the high part of a
Geoffrey Keating writes:
Geoff The documentation for the atomic operation patterns says things like:
This pattern must issue any memory barrier instructions such that the
pattern as a whole acts as a full barrier.
Geoff Should the barrier happen before the operation, after the operation,
Devang Patel wrote:
warning: initialization discards qualifiers from pointer target type
This warning can not be disabled using -Wno-cast-qual
(or any other warning flags). Is it intentional ?
It looks like we have been doing it this way since at least gcc-1.42.
The same code is there, with
On 18/04/2005, at 6:13 PM, David Edelsohn wrote:
Geoffrey Keating writes:
Geoff The documentation for the atomic operation patterns says things
like:
This pattern must issue any memory barrier instructions such that the
pattern as a whole acts as a full barrier.
Geoff Should the barrier happen
On Apr 18, 2005, at 6:29 PM, James E Wilson wrote:
Devang Patel wrote:
warning: initialization discards qualifiers from pointer
target type
This warning can not be disabled using -Wno-cast-qual
(or any other warning flags). Is it intentional ?
It looks like we have been doing it this way
Martin Koegler wrote:
I added to the i386 version the following code (using a unmodified gcc for the rest):
With this change, I can reproduce the problem.
I noticed that I get a failure for all types, not just array types.
This is different than what you described earlier, but perhaps the
Though of course, this doesn't mean that we can't have an option to
control it. -Wno-cast-qual doesn't seem like the right choice, as
there is no user cast here. Maybe something like -Wno-discard-
qual, where -Wdiscard-qual is the default.
I notice that these are pedwarns,
On Mon, Apr 18, 2005 at 02:48:27PM -0700, Geoffrey Keating wrote:
The documentation for the atomic operation patterns says things like:
This pattern must issue any memory barrier instructions such that the
pattern as a whole acts as a full barrier.
Should the barrier happen before the
, but nothing
worked. I had a similar problem with 'do_waitid' and I have attached
the patch just for the sake of discussion. Does anyone have some
insight on this? I am using binutils-2.15, glibc-2.3.4, 2.6.12-rc2
kernel headers and gcc-4.1.0-20050418. Thanks.
../sysdeps/unix/sysv/linux/waitid.c: In function
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18
06:10 ---
Subject: Bug 21001
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-18 06:10:45
Modified files:
gcc: ChangeLog tree-optimize.c
--- Additional Comments From kazu at cs dot umass dot edu 2005-04-18 06:11
---
Just checked in a patch.
--
What|Removed |Added
Status|NEW
--- Additional Comments From leslie dot barnes at amd dot com 2005-04-18
06:38 ---
(In reply to comment #2)
You want:
template
MyTypeSample list;
char *MyTypeSample::name = Hello\n;
The following code seg faults with g++ 3.4.3. If I remove the template ,
it won't compile. On g++
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18
07:05 ---
Subject: Bug 19216
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-18 07:05:28
Modified files:
gcc/testsuite : ChangeLog
Log message:
PR
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:18 ---
This is fixed by Paul T. Richard's namelist patch, but there still is a testcase
(gfortran.dg/pr19216.f) to commit on 4.0 branch.
--
What|Removed |Added
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-18
07:34 ---
Subject: Bug 20950
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-04-18 07:34:33
Modified files:
gcc/testsuite : ChangeLog
libgfortran:
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:39 ---
This is indeed legal, and fixed by Thomas's recent namelist patch. Will have to
be committed on 4.0 once it's open again.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:40 ---
Patch commited to mainline. Waiting for 4.0 to reopen.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:44 ---
This is fixed by Paul's recent namelist patch, applied on mainline. Will be
fixed on 4.0 once it's reopened.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:46 ---
This one is fixed by the recent namelist patch, will be fixed on 4.0 when it's
reopened.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:50 ---
Fixed by the recent namelist patch. Will be fixed on 4.0 once it's reopened.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:52 ---
The uppercase problem is fixed by Paul's recent patch on mainline (will be fixed
on 4.0 once it's reopened).
Leave this bug open until someone can confirm if leading space is required for
namelist output
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:54 ---
This is an extension indeed, and is incorporated in mainline by Paul's recent
namelist patch. Will be included in 4.0 when it reopens.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
07:59 ---
Confirm this bug. This is g77-only. Changed component to libf2c.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
08:02 ---
Fixed by Paul's recent namelist patch. Will be fixed on 4.0 when it's reopened.
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
08:05 ---
This is a duplicate of 18122 (which has just been fixed).
*** This bug has been marked as a duplicate of 18122 ***
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
08:05 ---
*** Bug 18591 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
08:06 ---
Fixed by Paul's recent namelist patch. Will be fixed on 4.0 when it's reopened.
--
What|Removed |Added
--- Additional Comments From falk at debian dot org 2005-04-18 08:10
---
(In reply to comment #6)
Hi. It can well be a libstdc++ problem, and indeed I can imagine ways to avoid
signed integers in the code. However, I'm not sure that someone will actually
do the work, given the
--- Additional Comments From adah at netstd dot com 2005-04-18 09:06
---
Function calls, memory barriers, (and lock operations?) are all overheads. I
would like that
* GCC provide extensions so that GCC users can use memory barriers and
threading calls in a platform-independent way,
--- Additional Comments From giovannibajo at libero dot it 2005-04-18
09:08 ---
A segfault in GCC is always a bug, even if the code is wrong. Would you please
open a new bugreport about it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17445
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-18
09:23 ---
I messed up the quotation too. :-( It should read:
#undef CPP_SPEC
#define CPP_SPEC \
%(cpp_cpu) \
%(cpp_arch) \
%{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic_} \
%{posix:-D_POSIX_SOURCE} \
--
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-04-18
09:33 ---
Updated patch:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01959.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-18 11:16
---
Appeared on hppa64-hpux between 2005-04-09 01:34 UTC and 2005-04-09 01:38 UTC.
I.e., caused by tree-cleanup-branch merge.
--
What|Removed |Added
template typename _Key,typename _Val,typename _KeyOfValue,typename
_Compare,typename _Alloc class _Rb_tree;
template typename _Key,typename _Compare,typename _Alloc class multiset{
multiset(_Compare const __comp,
typename _Rb_tree_Key,_Key,_Key ,_Compare,_Alloc ::allocator_type const
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-04-18 11:20
---
Appeared on x86_64-linux between 2005-04-12 21:33 UTC and 2005-04-12 21:37 UTC.
I.e., caused by
2005-04-12 Steven Bosscher [EMAIL PROTECTED]
Stuart Hastings [EMAIL PROTECTED]
Jan
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
12:03 ---
Using the testcase from comment #4, it seems clear that there is no check on
whether the slice selected has negative width...
atmp.2.dim[0].stride = 1;
atmp.2.dim[0].lbound = 0;
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-04-18 12:04 ---
here's another, simpler, testcase:
template typename T1,typename T2 class A; //it works with only 1 parameter
class B{
templatetypename U
void hoh(typename AU,U::depname a=AU,U::depname());
};
I'd
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-04-18 12:08 ---
fixed
--
What|Removed |Added
Status|NEW
--- Additional Comments From matz at suse dot de 2005-04-18 12:49 ---
So, any progress on this whole issue? I don't see either the pragmas in the
C++ headers, nor HJs changes to the c++ frontend (despite testcase) in CVS.
Just for the record, I see these problems (linkproblem with
--- Additional Comments From matz at suse dot de 2005-04-18 12:50 ---
Oh, and just annotating the testcase with the visibility push/pop #pragma
is not enough, probably because of the problem in the c++ frontend, HJ noted.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-04-18
13:12 ---
I think I found a patch for this one. See
http://gcc.gnu.org/ml/fortran/2005-04/msg00507.html
--
What|Removed |Added
Hello,
there must be a serious problem in
GNU C++ version 4.0.0 20050410 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 3.3.4 (pre 3.3.5 20040809) (SuSE Linux 9.2).
The same happens with GNU C++ version 4.0.0 20050410 when built with itself.
On a
--- Additional Comments From leslie dot barnes at amd dot com 2005-04-18
13:37 ---
(In reply to comment #4)
A segfault in GCC is always a bug, even if the code is wrong. Would you
please
open a new bugreport about it?
Sorry, I wasn't clear. The binary seg faults, not the
--- Additional Comments From pcarlini at suse dot de 2005-04-18 14:14
---
Hi Michael and thanks for asking: really, I'm lost in this tangle of front-end,
back-end and library issues. When I'm back from Oxford really want to move the
issue forward, somehow, asking all the knowledgeable
Consider:
int
foo (int *p)
{
int a = *p;
int b = p != 0;
*p = b;
if (b)
return a;
else
return 0;
}
Here is what I get with -O2 -fno-tree-dominator-opts
foo (p)
{
int b;
int a;
int D.1235;
bb 0:
a_3 = *p_2;
p_7 = p_2;
b_4 = p_7 != 0B;
*p_7 = b_4;
p_10 = p_7;
--- Additional Comments From matz at suse dot de 2005-04-18 14:22 ---
This patch fixes the regressions in khtml for us.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
--- Additional Comments From pcarlini at suse dot de 2005-04-18 14:23
---
This is news to me. Does this mean that vectorbool is not going to be
special-
cased any more? That seems like a very bad idea to me, since programs will
suddenly take 8 times as much memory (or even more).
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12884
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18879
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19467
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-18
14:42 ---
Michael, have you run the GCC testsuite with your patch? If not, please run on
several platforms and confirm that you get no regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20973
the
cause for this, the line reported, 17279, definitly is valid.
attaching source.
ICE with: gcc version 4.0.0 20050418 (prerelease)
works with: gcc-Version 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
--
Summary: ICE in do_nonmember_using_decl
Product: gcc
--- Additional Comments From matz at suse dot de 2005-04-18 14:51 ---
From
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01508.html
where I submitted the patch:
the problem in khtml. I've bootstrapped it with gcc 4.0 on
i686,x86_64,ppc,ppc64,ia64,s390 (s390x was breaking for
--- Additional Comments From sstrasser at systemhaus-gruppe dot de
2005-04-18 14:51 ---
Created an attachment (id=8676)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8676action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21087
--- Additional Comments From mckinlay at redhat dot com 2005-04-18 14:55
---
I don't think a gij test failure is expected. Array_3 is known to fail when
native compiled, however.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10353
1 - 100 of 194 matches
Mail list logo
