--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-25 06:05 ---
*** This bug has been marked as a duplicate of 28116 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-25 06:05 ---
*** Bug 28840 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-25 06:11 ---
Note the reduced testcase is:
struct QDateTime
{
QDateTime addSecs( int secs ) const;
int t;
};
QDateTime gridToDate(long x)
{
QDateTime date;
date = date.addSecs(1);
return date;
}
void whatsOnAt(long
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 06:25 ---
I am thinking this is undefined behavior because 120 is outside the range of
Three. In fact with -gnato, there is a constraint error:
In the output that follows, the three values of the type Three
are multiplied by
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 06:27 ---
This is not a bug as the code you are using is undefined as the Fortran program
is not calling a var-args C function, it is a Fortran function which always not
a var-args function.
--
pinskia at gcc dot gnu dot
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 06:31 ---
For 4.1.2, I get:
cc1: error: unrecognized command line option -imultilib
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28824
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 06:32 ---
For the mainline, I get cc1 reading from the stdin which is just plain weird.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28824
--- Comment #7 from bonzini at gnu dot org 2006-08-25 06:33 ---
reduced testcase from pr28840
struct QDateTime
{
QDateTime addSecs( int secs ) const;
int t;
};
QDateTime gridToDate(long x)
{
QDateTime date;
date = date.addSecs(1);
return date;
}
void whatsOnAt(long x,
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-25 06:34 ---
And I don't get an ICE though for either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28824
gfortran fails with an internal error when the attached file is compiled with
-O3 optimization:
error: edge from 62 to 64 should not be marked irreducible
error: basic block 64 should not be marked irreducible
error: edge from 64 to 53 should not be marked irreducible
internal
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-25 06:39 ---
This is a bug specific to Debian's GCC. There is no such ICE in the whole of
GCC.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 06:48 ---
*** This bug has been marked as a duplicate of 27735 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-25 06:48 ---
*** Bug 28843 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-25 06:59 ---
Here is another testcase, this time Fortran:
SUBROUTINE PG3CL9 (NUMSEG)
PARAMETER (NPMAX = 5000,
+NDMAX = 5000)
LOGICAL*4 INT
+ Z(NPMAX)
+ , INT(NPMAX)
--- Comment #11 from bonzini at gnu dot org 2006-08-25 07:09 ---
Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing
for __sync_fetch_and_add support) that the compiler should provide it as a
preprocessor symbol.
If you move
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-25 07:14 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-08-25 07:14 ---
Fixed.
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-08-25 07:14
---
Subject: Bug 28807
Author: pinskia
Date: Fri Aug 25 07:13:48 2006
New Revision: 116393
URL:
--- Comment #13 from bonzini at gnu dot org 2006-08-25 07:47 ---
PRE is eliminating
char *d.0_6;
d.0_6 = (char *) d_1;
by turning it into
char * prephitmp.24;
d.0_6 = prephitmp.24_14;
I think that not all casts should not be subject to PRE.
--
bonzini at gnu dot org
--- Comment #14 from bonzini at gnu dot org 2006-08-25 07:48 ---
Sorry, by turning it into
char * prephitmp.24;
# prephitmp.24_14 = PHI 1B(5), 2B(3);
d.0_6 = prephitmp.24_14;
I think that not all casts should be subject to PRE.
--
bonzini at gnu dot org changed:
--- Comment #12 from pcarlini at suse dot de 2006-08-25 08:08 ---
(In reply to comment #11)
Hmm, the test in GLIBCXX_ENABLE_ATOMIC_BUILTINS seems simple enough (testing
for __sync_fetch_and_add support) that the compiler should provide it as a
preprocessor symbol.
Yes, and a patch
--- Comment #3 from guillaume dot melquiond at ens-lyon dot fr 2006-08-25
08:34 ---
Which looks ok if we are passing via value but since we need to pass by
reference, the middle-end thinks we need a new stack space for it because it
does not know that D.1992 is not used after the
--- Comment #3 from S dot Sangwine at IEEE dot org 2006-08-25 08:39 ---
120 is outside the range of Three, but not outside the range of Three'Base,
which in my case is an 8-bit signed type with range -128 .. 127. So the correct
explanation of the problem is that the multiplication of 2
--- Comment #5 from kurkov at gorodok dot net 2006-08-25 08:50 ---
(In reply to comment #4)
Where did you get your list of symbol names and demangled strings?
My program uses C standard I/O routines instead of iostreams, to support
new-ABI C++ compilers that do not have complete C++
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-08-25 09:01
---
Mine. This regression was introduced at the time we got rid of
flag_fast_math and changed it to either flag_unsafe_math_optimizations or
flag_trapping_math.
+2001-03-07 Brad Lucier [EMAIL PROTECTED]
+
+
We were discussing some hashtable stuff in OOo recently, part of the outcome
was...
---
From: Herbert Duerr [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject:Optimization for empty hashtables
Date: Fri, 25 Aug 2006 11:15:50 +0200 (10:15 IST)
While analyzing the performance of
--- Comment #1 from caolanm at redhat dot com 2006-08-25 09:50 ---
Created an attachment (id=12137)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12137action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28844
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org
--- Comment #2 from pcarlini at suse dot de 2006-08-25 10:05 ---
Thanks a lot, I think we can certainly apply the patch. Are you willing to
check how are we doing in the tr1::unordered_ containers? I suspect there is
the same opportunity for improvement and frankly, at this point, we
--- Comment #3 from caolanm at redhat dot com 2006-08-25 10:15 ---
Created an attachment (id=12138)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12138action=view)
and add some smaller primes to the start of the list
An additional part to this puzzle...
From: Herbert Duerr
--- Comment #4 from caolanm at redhat dot com 2006-08-25 10:19 ---
On a brief inspection the trl hashtable doesn't look like it really suffers
from these problems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28844
--- Comment #5 from pcarlini at suse dot de 2006-08-25 10:21 ---
Indeed, I was about to post similar considerations: in tr1::unordered_ the
table starts from *2* and I think it's fine. I'm not so happy about changing
now the table of the legacy ext containers, minimally maintained but
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-08-25 10:32 ---
Subject: Bug 28829
Author: rguenth
Date: Fri Aug 25 10:32:03 2006
New Revision: 116395
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116395
Log:
2006-08-25 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #6 from caolanm at redhat dot com 2006-08-25 10:32 ---
Sure, up to you, but I'd say you'd still be pretty safe adding two smaller
starting hash sizes.
This doesn't actually affect most OOos (at least for 95% of OOo's which exist)
which are normally built against stlport for
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-08-25 10:32 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pcarlini at suse dot de 2006-08-25 10:36 ---
(In reply to comment #6)
Sure, up to you, but I'd say you'd still be pretty safe adding two smaller
starting hash sizes.
Then, let's go with the minimal fix. Really, we decided time ago to only
minimally maintain those
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-08-25 10:39 ---
We now have gcc.c-torture/execute/mayalias-2.c which crashes this way on x86_64
at -O3 -g.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
--- Comment #8 from kkojima at gcc dot gnu dot org 2006-08-25 10:56 ---
And when the other code to handle abnormal edges is fixed, we should not
even try to insert a mode set on an abnormal edge, so the above code can
be changed into
gcc_assert (! (eg_flags
--- Comment #8 from pcarlini at suse dot de 2006-08-25 11:04 ---
The minimal fix is not correct: the implementation of find assumes a number of
buckets 0, try:
hash_setint hs(0);
hs.find(1);
it leads to a float exception. Sorry, we are not going to do anything for this
issue.
--- Comment #3 from cyan+gcc at compsoc dot nuigalway dot ie 2006-08-25
11:06 ---
(In reply to comment #2)
the Fortran program
is not calling a var-args C function,
I don't understand what you mean. The fortran code calls the test function,
which is written in C (called test_ due to
--- Comment #9 from amylaar at gcc dot gnu dot org 2006-08-25 11:07 ---
(In reply to comment #8)
Do you mean the patch like this?
Yes, indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-08-25 11:14 ---
Working on a fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-08-25 11:15 ---
Working on a fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jsm28 at gcc dot gnu dot org 2006-08-25 11:15 ---
Working on a fix.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from kkojima at gcc dot gnu dot org 2006-08-25 11:25
---
I've confirmed that it fixes the build failure on sh4-linux. I'll
send it to gcc-patches after the test on i686-linux is completed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
--- Comment #7 from falk at debian dot org 2006-08-25 12:07 ---
Can you still reproduce this? As Andrew points out, it is probably fixed...
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-08-25 12:57
---
Hi Paul,
sorry for the late reply, I was away for a few days.
I compiled the most recent gcc sources, and there still appears to be some
bad memory access inside gfortran, which causes the compiler to
--
shinwell at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |shinwell at gcc dot gnu dot
|dot org
--
shinwell at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |shinwell at gcc dot gnu dot
|dot org
--- Comment #8 from paulthomas2 at wanadoo dot fr 2006-08-25 13:25 ---
Subject: Re: [gfortran: 4.1, 4.2 regression] ICE on valid
code
martin,
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-08-25
12:57 ---
Hi Paul,
sorry for the late reply, I was away for a
--
shinwell at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |shinwell at gcc dot gnu dot
|dot org
--- Comment #11 from bonzini at gnu dot org 2006-08-25 13:43 ---
This potentially affects i686-pc-linux-gnu as it also uses the mode switching
code. I think this should go in.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #12 from dje at gcc dot gnu dot org 2006-08-25 13:54 ---
Subject: Bug 28753
Author: dje
Date: Fri Aug 25 13:53:39 2006
New Revision: 116400
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116400
Log:
PR target/28753
* config/rs6000/rs6000.md
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-25 14:08 ---
(In reply to comment #3)
(In reply to comment #2)
the Fortran program
is not calling a var-args C function,
I don't understand what you mean. The fortran code calls the test function,
which is written in C
--- Comment #13 from dje at gcc dot gnu dot org 2006-08-25 14:09 ---
Patch applied.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Configured
with: ../configure --target=sparc-sun-solaris2.9
--prefix=/local/devel/toolchain41/sparc-sun-solaris2.9
--libdir=/local/devel/toolchain41/sparc-sun-solaris2.9/lib
--libexecdir=/local/devel/toolchain41/sparc-sun-solaris2.9/lib
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 14:18 ---
Solaris is not one of the targets that supports -rdynamic.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from amylaar at gcc dot gnu dot org 2006-08-25 14:33
---
(In reply to comment #11)
This potentially affects i686-pc-linux-gnu as it also uses the mode switching
code. I think this should go in.
As far as I can see, the i387 mode switching is already completely
--- Comment #6 from drow at gcc dot gnu dot org 2006-08-25 14:35 ---
We're pruning excessively; I'll track down why.
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |drow at gcc dot gnu dot org
|dot org
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-08-25 14:36
---
Created an attachment (id=12139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12139action=view)
new testcase
Compile with gfortran -c lensing.f90
and with gfortran -c -I. lensing.f90
--
--
drow at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|drow at gcc dot gnu dot org |unassigned at gcc dot gnu
|
--- Comment #10 from martin at mpa-garching dot mpg dot de 2006-08-25
14:37 ---
Perhaps you can let me have an idea of the kind of code that is doing
this? Is this a continuation of the derived type problem or did it
exist prior to the patch of a week back?
I don't think it
--- Comment #2 from pluto at agmk dot net 2006-08-25 14:38 ---
really?
please look at this.
[1] cross build on linux machine:
sparc-sun-solaris2.9-g++ backtracexx.cpp -o libbacktracexx.so -shared -ldl
-Wall -Werror -pedantic \
-O3 -fpic -funwind-tables -fno-exceptions
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-25 14:43 ---
So read the docs, solaris does not support the option.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
hosking at cs dot purdue dot edu wrote:
--- Comment #13 from hosking at cs dot purdue dot edu 2006-08-24 15:27
---
Is this enough?
Here is the dump output, followed by stack traces at the resize and remove
points (the remove goes on to fail).
So, this edge can't exist.
Note:
--- Comment #14 from dberlin at gcc dot gnu dot org 2006-08-25 15:19
---
Subject: Re: remove_phi_node attempts removal
of a phi node resized by resize_phi_node
hosking at cs dot purdue dot edu wrote:
--- Comment #13 from hosking at cs dot purdue dot edu 2006-08-24 15:27
--- Comment #7 from jsm28 at gcc dot gnu dot org 2006-08-25 15:44 ---
I see no evidence for HOST_WIDE_INT dependence or for this still being present
in 4.2 on any platform. It looks like it was fixed by
2006-04-20 Jakub Jelinek [EMAIL PROTECTED]
* c-pretty-print.c
--
pbrook at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot
|dot org
--- Comment #13 from amylaar at gcc dot gnu dot org 2006-08-25 16:33
---
(In reply to comment #12)
As far as I can see, the i387 mode switching is already completely broken,
because it treats the different modes of a single mode-switchable entity
as separate entities.
On second
--- Comment #14 from bonzini at gnu dot org 2006-08-25 16:36 ---
On second thought, this can work with the current implementation of
mode-switching using pre_edge_lcm, since it will never insert a computation
in a path if it hasn't been there before.
Yes, and that's why I think the
--- Comment #5 from kargl at gcc dot gnu dot org 2006-08-25 16:38 ---
I don't understand what you mean. The fortran code calls the test function,
which is written in C (called test_ due to name mangling). test_ is indeed a
variable-args function:
void test_(int *test, ...).
--- Comment #6 from nathan at gcc dot gnu dot org 2006-08-25 16:52 ---
2006-08-25 Nathan Sidwell [EMAIL PROTECTED]
PR c++/27787
* decl.c (make_typename_type): Only try and resolve it when
context is not dependent. Refactor.
* decl2.c (check_classfn):
--- Comment #7 from nathan at gcc dot gnu dot org 2006-08-25 16:56 ---
Subject: Bug 27787
Author: nathan
Date: Fri Aug 25 16:56:07 2006
New Revision: 116409
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116409
Log:
cp/
PR c++/27787
* decl.c (make_typename_type):
--- Comment #15 from amylaar at gcc dot gnu dot org 2006-08-25 17:01
---
(In reply to comment #13)
For any transparent sub-graph, considering the expression anticipatable
in this graph is beneficial if the sum of the frequencies of outgoing edges
on which the expression is
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-08-25 17:03
---
Subject: Bug 28056
Author: mmitchel
Date: Fri Aug 25 17:03:50 2006
New Revision: 116410
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116410
Log:
PR c++/28056
* decl.c (grokdeclarator):
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-08-25 17:04
---
Subject: Bug 28056
Author: mmitchel
Date: Fri Aug 25 17:04:35 2006
New Revision: 116411
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116411
Log:
PR c++/28056
* g++.dg/parse/local1.C: New
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-08-25 17:05
---
Subject: Bug 28056
Author: mmitchel
Date: Fri Aug 25 17:05:30 2006
New Revision: 116412
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116412
Log:
PR c++/28056
* decl.c (grokdeclarator):
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-08-25 17:05
---
Fixed in 4.1.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2006-08-25 17:09
---
On x86-64 linux:
(gdb) set args lensing.f90
(gdb) r
Starting program: /home/jerry/bin/f951 lensing.f90
Warning: Reading file 'stdin' as free form.
.file stdin
In file :598
use ModelParams
--
nathan at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org
--- Comment #5 from pcarlini at suse dot de 2006-08-25 17:18 ---
I'm looking a bit into this: one puzzling thing is that the corresponding leak
as reported by valgrind amounts to *zero* bytes... It may well be that
something is wrong in the testing machinery / internal leak detection
--- Comment #7 from drow at gcc dot gnu dot org 2006-08-25 17:27 ---
Testing a fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27017
gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10)
g++ wants a Moo(const Moo) in this code:
class Moo
{
Moo() { }
Moo(const Moo) { }
public:
Moo(int) { }
};
void xyz(const Moo )
{
}
int main()
{
xyz(Moo(0));
return 0;
}
test.cpp:5: error:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 17:41 ---
Actually the standard as written requires this behavior, even though the copy
constructor is not called. Anyways the standard has changed with DR 391 so
this is a dup of bug 25950.
*** This bug has been marked as
--- Comment #24 from pinskia at gcc dot gnu dot org 2006-08-25 17:41
---
*** Bug 28846 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org
--- Comment #16 from amylaar at gcc dot gnu dot org 2006-08-25 18:52
---
Subject: Bug 16876
Author: amylaar
Date: Fri Aug 25 18:51:57 2006
New Revision: 116424
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116424
Log:
gcc:
PR tree-optimization/16876
* c-typeck.c
--- Comment #17 from dje at gcc dot gnu dot org 2006-08-25 18:56 ---
Subject: Bug 27075
Author: dje
Date: Fri Aug 25 18:56:08 2006
New Revision: 116425
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116425
Log:
PR target/27075
* config/rs6000/rs6000.c
--- Comment #18 from dje at gcc dot gnu dot org 2006-08-25 18:56 ---
patch committed.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #15 from drow at gcc dot gnu dot org 2006-08-25 18:57 ---
I don't think I can sort this one out. I think the easiest solution will be to
check when marking a function as reachable whether it has an abstract origin,
and if so set a flag in the abstract origin preventing its
--- Comment #12 from tbm at cyrius dot com 2006-08-25 19:05 ---
Update: mzero6.c fails because of this ICE too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
--- Comment #19 from dje at gcc dot gnu dot org 2006-08-25 19:06 ---
Subject: Bug 27075
Author: dje
Date: Fri Aug 25 19:06:18 2006
New Revision: 116426
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116426
Log:
PR target/27075
* config/rs6000/rs6000.c
gcc: Internal error: Segmentation fault (program as)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-3.3/README.Bugs.
This is waht gcc gives me when I compile with
gcc.dg/noncompile/pr16876 should actually compile with a warning, rather
than fail with an error.
Some work on related issues has been done before in:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00772.html
I suppose in this code:
case ic_argpass:
case ic_argpass_nonproto:
/* ???
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|c |target
--- Comment #1 from ulvinge at gmail dot com 2006-08-25 19:13 ---
I fogot to mention, that the line that caused the bug is this line
\n lea ebx, ebx+buffer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28847
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 19:15 ---
This is not a GCC issue really but a bug in as, yes we should not report to
file a bug here but that is PR 2252.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ulvinge at gmail dot com 2006-08-25 19:27 ---
OK, but what is PR 2252 ?
Nevermind, it was easy to fix...
just change
lea ebx, ebx+buffer
to
lea ebx, buffer+ebx
Simple, but it's still a bug.
I wont care.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28847
--- Comment #7 from kazu at gcc dot gnu dot org 2006-08-25 19:31 ---
Reproduced. Looking at this now.
--
kazu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tbm at cyrius dot com 2006-08-25 19:38 ---
FWIW, I cannot reproduce this with gcc 4.0.4 20060730 on hppa-linux-gnu, nor
with current 4.1 or 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21122
1 - 100 of 173 matches
Mail list logo
