Paolo Bonzini wrote:
Jack Howarth wrote:
+ if (y == -1 x 0 ((unsigned)x) == -(unsigned)x)
return DIVMOD_OVERFLOW;
or just a much clearer
if (y == -1 x == INT_MIN)
return DIVMOD_OVERFLOW;
(possibly with a #include limits.h at the top).
Nit picking -
x
Some ports, notably MMIX, are using different definitions of
EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because
the same instruction may be considered invalid in reload.c and valid by
recog.c.
The opposite would be bad because after reload everything must still
adhere
Hello everyone,
I am upgrading a cross compiler from 3.2 to 3.4.6
I had to change some of the TARGET description macros
in target.h file
for otherwise while building i am getting attempt to
use poisoned errors
Presently what is written in target.h is
1. #define CPP_PREDEFINES \
2. #define CONST_COSTS(RTX, CODE, OUTER_CODE) \
case CONST_INT: \
return target_const_costs (RTX, OUTER_CODE);
\
case CONST: \
return 5;
On Thu, 24 Aug 2006, Paolo Bonzini wrote:
Some ports, notably MMIX, are using different definitions of
EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because
the same instruction may be considered invalid in reload.c and valid by
recog.c.
When I wrote that code, accounting
I have been able to use the command...
make -k check RUNTESTFLAGS='--target_board unix{,-m64}'
to check my multilib gcc trunk build on Darwin ppc from within
the darwin_objdir/gcc directory of the build tree. However
this doesn't seem to allow both the -m32 and -m64 testsuite
runs for the
Hans-Peter Nilsson wrote:
Some ports, notably MMIX, are using different definitions of
EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because
the same instruction may be considered invalid in reload.c and valid by
recog.c.
When I wrote that code, accounting for
You should look at a small back-end, e.g. pdp11, and see how to rewrite
these macros into functions (target hooks).
Its been a great help... thanks for the direction.
When i looked into the machine macros of GNU supported
processors i found that all of the macros previously
defined in
[no private mail]
Just to move code from target.h to target.c.
Paolo
I didnt get you?
Do you mean to say that i should also move the code to
stick to standard ?
You should move code from target.h to target.c, or it won't compile.
Macros became target hooks defined in the target.c
Joern RENNECKE [EMAIL PROTECTED] wrote:
My simulator now segfaults for every single execution test built with
mainline; when I try gdb, it also segfaults,
somewhere in the dwarf handling code.
Unless someone comes up with a viable concept how to maintain sh64
support in gcc, I think we have
Note: forwarded message attached.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com ---BeginMessage---
Hai,
i dont know the corresponding macro in
I should add that I see the same problem if I execute...
make -k check RUNTESTFLAGS='--target_board unix{,-m32}'
...from the toplevel of the linux_obj directory on gcc trunk
built on a x86_64 Fedora Core 5 machine. The behavior is the
same as on darwin. If I execute the above command from
Hi,
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int - string, float - string, double- string).
After changing the ostringstream conversion to sprintf, the crash in the
On Aug 23, 2006, at 4:43 PM, Jack Howarth wrote:
--- gcc-4.2-20060822/gcc/testsuite/lib/prune.exp.org2006-08-23
18:33:56.0 -0400
+++ gcc-4.2-20060822/gcc/testsuite/lib/prune.exp2006-08-23
18:41:28.0 -0400
@@ -43,6 +43,7 @@
regsub -all (^|\n)\[^\n\]*file path
Mike,
I just created PR28837 with the patch to prune.exp that
prunes the ld64 warnings. I have only tested this with the
core gcc at the moment because I can't get...
make -k check RUNTESTFLAGS='--target_board unix{,-m64}'
...to work from the toplevel of the darwin_obj directory...
On Thu, Aug 24, 2006 at 09:28:11AM -0400, Jack Howarth wrote:
I should add that I see the same problem if I execute...
make -k check RUNTESTFLAGS='--target_board unix{,-m32}'
...from the toplevel of the linux_obj directory on gcc trunk
built on a x86_64 Fedora Core 5 machine. The
On Thu, Aug 24, 2006 at 12:02:25PM -0400, Jack Howarth wrote:
Mike,
I just created PR28837 with the patch to prune.exp that
prunes the ld64 warnings. I have only tested this with the
core gcc at the moment because I can't get...
make -k check RUNTESTFLAGS='--target_board unix{,-m64}'
Janis,
THANKS! Using either...
make -k check RUNTESTFLAGS=--target_board=unix'{-m32,}'
or
make -k check RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
..works from the toplevel directory (at least for x86_64
on Fedora Core 5...I'll try darwin when I get home to my G5).
Jack
On Thu, 24 Aug 2006, Paolo Bonzini wrote:
Anyway, I was not meaning to *not* account for anything, but just to
replace REG_OK_STRICT with checks on reload_in_progress and
reload_completed. I understand the semantics that you wanted for 'U'.
The bug may be that in some cases, 'U' is checked
Jordan, Laszlo (GE Healthcare) wrote:
Hi,
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int - string, float - string, double- string).
After changing the ostringstream
On Thu, Aug 24, 2006 at 04:36:22PM +0200, Jordan, Laszlo (GE Healthcare) wrote:
Hi,
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int - string, float - string, double-
Paul Brook [EMAIL PROTECTED] writes:
On Tuesday 22 August 2006 20:14, Mike Stump wrote:
I hate to even bring this up, but... should things like:
int m[1 27] = {0};
be put in .bss? I'm tempted to say no, if you want that, you have to
remove {0}.
What makes you say this?
[EMAIL PROTECTED] (Jack Howarth) writes:
Is it the expected behavior for dejagnu to always report warnings
as errors in the test for excess errors check? Is this a design
decision or just how dejagnu currently works? I ask because the
current output of test for excess errors when a FAIL
else if (rld[r].out_reg == 0
rld[r].in != 0
((REG_P (rld[r].in)
REGNO (rld[r].in) = FIRST_PSEUDO_REGISTER
!REGNO_REG_SET_P (reg_has_output_reload,
REGNO (rld[r].in))
|| (REG_P
On Thu, Aug 24, 2006 at 04:36:22PM +0200, Jordan, Laszlo (GE Healthcare) wrote:
Hi,
I had a crash in our software, which occured randomly. The valgrind logs
and the stack trace pointed to a code snippet, which uses ostringstream
for data conversion. (int - string, float - string,
gcc try.c -o try would give me linking problem
/tmp/ccQOkXtu.o: In function `serial_echo_print':
try.c:(.text+0x31e): undefined reference to `__inb'
try.c:(.text+0x34a): undefined reference to `__outb'
try.c:(.text+0x360): undefined reference to `__inb'
try.c:(.text+0x387): undefined reference
wizard00 [EMAIL PROTECTED] writes:
gcc try.c -o try would give me linking problem
/tmp/ccQOkXtu.o: In function `serial_echo_print':
try.c:(.text+0x31e): undefined reference to `__inb'
try.c:(.text+0x34a): undefined reference to `__outb'
try.c:(.text+0x360): undefined reference to `__inb'
--- Comment #4 from ian at airs dot com 2006-08-24 06:20 ---
Where did you get your list of symbol names and demangled strings?
As Andrew has pointed out, there seem to be a few different issues here:
different spacing, different qualifier order, different handling of floating
point
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-08-24 06:51 ---
Confirmed. As the other one was a C++ frontend problem this one may be solved
in the C frontend then.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jz201115 at zodiac dot mimuw dot edu dot pl 2006-08-24
10:22 ---
Andrew,
So do you want to say this is not a bug? I know the class isn't intersting
but I think it shouldn't have size equal to 0.
Thanks,
Janek
--
Attached (gzipped) fbmmx.i (from Xorg 6.8.2 xc/programs/Xserver/fb/fbmmx.c)
gives fbmmx.c:871: internal compiler error: in push_reload, at reload.c:1303
when compiled with 4.1.1 on i686-linux-gnu. This is probably a regression as
I've previously compiled the same Xorg release fine with 4.1.0.
GCC
--- Comment #1 from peter at empeg dot com 2006-08-24 10:37 ---
Created an attachment (id=12124)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12124action=view)
gzipped preprocessed source of testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28833
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-08-24 10:39 ---
*** This bug has been marked as a duplicate of 28776 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-08-24 10:39
---
*** Bug 28815 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-24 10:55 ---
Fixed in 4.1.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Testcase that crashes at -O3 -g:
struct S { short x; };
typedef struct S __attribute__((__may_alias__)) test;
int f() {
int a=10;
test *p=(test *)a;
p-x = 1;
return a;
}
int main() {
if (f() == 10)
__builtin_abort();
return 0;
}
-
mayalias-2.c:2: internal
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-24 11:06 ---
This worked in 3.4.0 so this is a regression. Note this is the testcase for
28807 which I was using for testing so the testcase might be added to the
testsuite by the time someone gets around to looking into the
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-24 11:12 ---
This is going to be hard to fix really, unless we make explicate the target's
behavior for passing structs (via value or by reference).
Right now we get:
D.1992 = f () [return slot optimization];
g (D.1992)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-24 11:16 ---
I wonder if this is related to PR 28834 at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
Multiplication of a variable of a user-defined integer type with range 0 .. 2
by an integer literal causes incorrect result in the case when the variable has
value 2. A negative result is given even though the variable and literal are
positive.
Found this error with Gnat 3.4.6 (AdaCore Libre
--- Comment #1 from S dot Sangwine at IEEE dot org 2006-08-24 11:39 ---
Created an attachment (id=12126)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12126action=view)
Stand-alone Ada main program that demonstrates the error.
--
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-08-24 13:03
---
One problem is that in fold-const.c we use HONOR_XXX macros, while in
builtins.c
folding we use MODE_HAS_XXX. HONOR_XXX changes with -ffinite-math-only and
friends, while MODE_HAS_XXX not (of course).
So to make
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-08-24 13:17
---
Created an attachment (id=12127)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12127action=view)
patch
I'm going to improve the situation by following the principle of least surprise
and not relying on the
--- Comment #19 from hubicka at gcc dot gnu dot org 2006-08-24 13:30
---
Subject: Bug 26881
Author: hubicka
Date: Thu Aug 24 13:30:45 2006
New Revision: 116374
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116374
Log:
PR debug/26881
* cgraph.c: Fix comments.
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-08-24 13:41
---
See also the target specific fix
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00873.html
and the middle-end fix
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00874.html
(as this is not a regression this may
pinskia at gcc dot gnu dot org wrote:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-24 04:27
---
Another interesting case would be (but which could be handled by VRP):
int
foo (int a)
{
a = a!=0;
a = a!=0;
a = a!=0;
a = a!=0;
a = a!=0;
return a;
}
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-08-24 14:43 ---
Subject: Re: [tree-ssa] Optimize cascaded a
= a == 0;
pinskia at gcc dot gnu dot org wrote:
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-24 04:27
---
Another interesting case would be
A third-party library I'm using doesn't compile with gcc 4.1.1 anymore (it
still did with 4.0). The problem is that some header files contain a code
fragment (I've stripped it down) like this:
#include iostream
using namespace std;
template class F, class R class I {
public:
int
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-24 14:57 ---
4.0.x was incorrect in accepting this code in the first place.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-08-24 15:16 ---
Mine, all mine.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from patchapp at dberlin dot org 2006-08-24 15:18 ---
Subject: Bug number PR 28807
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00878.html
--
--- 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). The edge being split is:
(gdb) p *e
$9 = {
src = 0x425cc8d0,
dest =
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-08-24 15:32 ---
(In reply to comment #5)
I think the only sane way to handle this is not to emit any mode
switching code for exception edges at the potential trapping site,
and make the exception handling code assume no
Currently the ld64 on Darwin seems to create warnings of the form...
can't find atom for N_GSYM stabs i:G(0,2) in /var/tmp//cc6KtMzX.o
when compiling Fortran COMMON blocks at -m64 with the -g flag. These warnings
incorrectly cause about 38 apparent fortran testsuite failures on Darwin. This
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-08-24 15:42
---
I wonder if this is related to PR 28834 at all.
The ICE stems from a new sanity check in the DWARF-2 back-end and we have
fixed the problem in Gigi.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28591
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-24 15:50 ---
Janis,
Could you run a regression hunt on this bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jason at gcc dot gnu dot org 2006-08-24 15:54 ---
Subject: Bug 27714
Author: jason
Date: Thu Aug 24 15:54:39 2006
New Revision: 116379
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116379
Log:
PR c++/27714
* pt.c (push_template_decl_real): A
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-08-24 16:22 ---
(In reply to comment #0)
Actually, I think this code:
/* If this is an abnormal edge, we'll insert at the end
of the previous block. */
if (eg-flags EDGE_ABNORMAL)
--- Comment #3 from jason at gcc dot gnu dot org 2006-08-24 16:34 ---
Subject: Bug 27714
Author: jason
Date: Thu Aug 24 16:34:46 2006
New Revision: 116380
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116380
Log:
PR c++/27714
* pt.c (push_template_decl_real): A
--- Comment #4 from jason at gcc dot gnu dot org 2006-08-24 16:35 ---
Subject: Bug 27714
Author: jason
Date: Thu Aug 24 16:35:03 2006
New Revision: 116381
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116381
Log:
PR c++/27714
* pt.c (push_template_decl_real): A
--- Comment #5 from jason at gcc dot gnu dot org 2006-08-24 16:35 ---
.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from jmbnyc at gmail dot com 2006-08-24 16:47 ---
Subject: Re: gcc -g and shared objects
I finally updated my system today. I now have:
[EMAIL PROTECTED] BUtil]$ uname -a
Linux localhost.localdomain 2.6.17-1.2174_FC5smp #1 SMP Tue Aug 8
16:00:39 EDT 2006 i686 i686 i386
--- Comment #2 from simon_baldwin at yahoo dot com 2006-08-24 16:53 ---
You didn't miss anything. There's no bug here, just a request for a new
warning message.
As you note, the const-volatile qualifications in the cast have no meaning, and
are completely ignored by the compiler.
I'll try to get around it as soon as I can. Thanks.
It has been a month... would be nice if you could look at it soon.
Thanks for poking, I got stuck on a strange bug that causes make to
assert while building the Java bits and I haven't gotten around to
fixing it. I'll try and get
--- Comment #18 from ams at gnu dot org 2006-08-24 18:05 ---
Subject: Re: [4.2 Regression] GNU Hurd bootstrap error: 'OPTION_GLIBC'
undeclared
I'll try to get around it as soon as I can. Thanks.
It has been a month... would be nice if you could look at it soon.
Thanks for
--- Comment #11 from dje at gcc dot gnu dot org 2006-08-24 18:19 ---
Created an attachment (id=12128)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12128action=view)
allow immediate load into CRs
Ulrich Weigand pointed out the instruction that is failing is a secondary
reload
Passing -pthread while compiling a trivial program does not work:
[EMAIL PROTECTED]:~$ gcc -pthreads test.c
gcc: unrecognized option '-pthreads'
Looking at bug 20705, it seems -pthread should be supported.
--
Summary: LIB_SPECS lacks pthread
Product: gcc
--- Comment #1 from mbanck at debian dot org 2006-08-24 19:12 ---
Created an attachment (id=12129)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12129action=view)
gcc.libspec.diff
Possible (untested) fix, not taking line lenghts into account.
--
--- Comment #15 from amylaar at gcc dot gnu dot org 2006-08-24 19:13
---
Created an attachment (id=12130)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12130action=view)
patch
I think this should do the trick.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
--- Comment #8 from tobias dot burnus at physik dot fu-berlin dot de
2006-08-24 19:43 ---
*ping*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
--- Comment #9 from paulthomas2 at wanadoo dot fr 2006-08-24 21:40 ---
Subject: Re: [4.1 only] gfortran: matmul produces wrong
result
Tobias,
Seeing as it is you, I just put a first version on to cook; I simply
copied everything below the line
if (GFC_DESCRIPTOR_RANK (retarray) ==
--- Comment #5 from howarth at nitro dot med dot uc dot edu 2006-08-24
21:44 ---
The testcase presented here appears to work as expected on Darwin when gcc
trunk is built with Geoff Keating's proposed patch to add TImode support to
Darwin...
--- Comment #25 from amylaar at gcc dot gnu dot org 2006-08-24 20:04
---
Created an attachment (id=12131)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12131action=view)
This patch checks if the warning location is within cfun.
I probably won't find CPU cycles to test this
--- Comment #40 from amylaar at gcc dot gnu dot org 2006-08-24 20:50
---
(In reply to comment #37)
For a proper patch, the number should of course be a PARAM and I think using
bitmap_count_bits penalizes the common case too much (walking the whole bitmap
is cache expensive even for
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-08-24
22:12 ---
Strangely, while the testcase first presented here...
int printf(const char *, ...);
typedef int TItype __attribute__((mode(TI)));
TItype x = -1;
int main(void) { printf(%f %f\n, (float)x, (double)x);
/ccflUJcQ.s
GNU C version 4.2.0 20060824 (experimental) (x86_64-linux-uclibc)
compiled by GNU C version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 3bea3173e03ea3601524f7ad8491537d
test-lock.c
--- Comment #1 from aldot at gcc dot gnu dot org 2006-08-24 22:59 ---
Created an attachment (id=12132)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12132action=view)
preprocessed from a testcase of plain gettext-0.15
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28839
--- Comment #3 from janis at gcc dot gnu dot org 2006-08-24 23:35 ---
A regression hunt on powerpc-linux identified this patch:
http://gcc.gnu.org/viewcvs?view=revrev=87036
r87036 | dpatel | 2004-09-03 17:10:40 + (Fri, 03 Sep 2004)
--
janis at gcc dot gnu dot org
--- Comment #17 from yangdh at cableplus dot com dot cn 2006-08-24 23:55
---
Any progress in solving this problem? I still have the same problem with my G5
running ppc64 linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23158
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-08-25 00:02
---
(In reply to comment #17)
Any progress in solving this problem? I still have the same problem with my G5
running ppc64 linux.
This was not a bug in the new version of GCC but the older one which is no
longer
--- Comment #10 from dannysmith at gcc dot gnu dot org 2006-08-25 00:24
---
Subject: Bug 28528
Author: dannysmith
Date: Fri Aug 25 00:24:10 2006
New Revision: 116392
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=116392
Log:
PR driver/28528
* g++spec.c
--- Comment #11 from dannysmith at users dot sourceforge dot net
2006-08-25 00:27 ---
Fixed on mainline.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
internal compiler error: in expand_expr_addr_expr_1, at expr.c:6336
--
Summary: internal compiler error
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo:
--- Comment #1 from eemax at web dot de 2006-08-25 00:39 ---
Created an attachment (id=12133)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12133action=view)
test case (gzipped because it's too big)
[/usr/source/Radio-TV/qttv_0.0.1/qttv] dc(1)$ gcc -v
Using built-in specs.
Target:
Error trying to compile Quantlib with gcc-4.1.1:
emgsydapp42-ladamson [View: ]: /opt/gcc/gcc-4.1.1-x86-solaris2.10/bin/g++
-DHAVE_CONFIG_H -I. -I. -I../../../ql -I../../.. -I../../..
-I/home/qad/lee/x86_sol_view/usr/dev/ccase/vobs/development/imagine_vob/imagine_release/emg_quant/boost
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-25 01:20 ---
Confirmed by Janis.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from lee dot adamson at macquarie dot com 2006-08-25 01:22
---
Created an attachment (id=12134)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12134action=view)
Preprocessed source.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28841
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2006-08-25
01:36 ---
Interestingly out of the lines in the fp-int-convert-timode testcase, the one
that causes the abort is...
TEST_I_F(TItype, UTItype, float, FLT_MANT_DIG);
The other two lines for double and long
--- Comment #47 from amacleod at redhat dot com 2006-08-25 01:37 ---
Created an attachment (id=12135)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12135action=view)
patch to resolve some of the SSA to Normal slowdowns.
By re-implementing the live on entry/exit code, I get the
--- Comment #48 from amacleod at redhat dot com 2006-08-25 01:42 ---
Created an attachment (id=12136)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12136action=view)
Patch for the remaining SSA to Normal time issues
I've attached a patch to address the slowdowns in TER. Again, not
--- Comment #49 from amacleod at redhat dot com 2006-08-25 01:56 ---
links to the 2 notes on gcc-patches:
live range changes: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00895.html
TER changes: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00896.html
--
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2006-08-25
03:59 ---
After looking at this in detail, only six of the testcases for the single
precision float conversions
in TEST_I_F(TItype, UTItype, float, FLT_MANT_DIG) fail. These are...
TEST_I_F_VAL (I, F, HVAL0S (P,
--- Comment #2 from fang at csl dot cornell dot edu 2006-08-25 04:10
---
possibly PR 28358 and/or PR 28116
--
fang at csl dot cornell dot edu changed:
What|Removed |Added
There is leftover markup from the texinfo source in the manual page for gcc(1).
Specifically, search for @pxref and @anchor, which shouldn't be showing up in
the output.
Also, the documentation for -print-multi-lib seems to be mangled:
-print-multi-lib
Print the mapping from multilib
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 04:31 ---
This is a dup of bug 26757 and was fixed in 4.1.2.
*** This bug has been marked as a duplicate of 26757 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from pinskia at gcc dot gnu dot org 2006-08-25 04:31
---
*** Bug 28841 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 04:52 ---
*** This bug has been marked as a duplicate of 27832 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-08-25 04:52 ---
*** Bug 28842 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-08-25 05:16 ---
Testcase:
static int ready[10];
void test_once (int t,int t1)
{
int i, repeat;
for (i = 0; i 10; i++)
{
ready[i] = 0;
if (t1)
if (b())
abort ();
}
if (t)
abort ();
}
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-08-25 05:17 ---
Confirmed, a regression from 4.1.2.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
100 matches
Mail list logo
