-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Faylor wrote:
On Wed, May 31, 2006 at 11:37:51PM +0200, FX Coudert wrote:
And I forgot to ask: who the heck is supposed to set USE_MINGW_MSYS?
(grep is soo sloow on my win32 machine)
For the record, I don't do Msys. Please
On Thu, 2006-06-01 at 03:43, Mike Stump wrote:
Mine was designed to do two things, figure out if the results are
interesting and not send email, if they are not, and to show
engineers the `interesting' detailed results in priority order. It's
meant to be run daily, and on good days, it
Vladimir Makarov wrote:
...
I am agree with this. Two months ago Maxim submitted patches which
affects only ia64 except one thing affecting all targets - the patch
which builds more scheduling regions and as consequence permits more
aggressive interblock scheduling.
Insn scheduling before
I get the following failure while building gcc 4.2 on hppa:
checking for pid_t... no
checking for library containing strerror... configure: error: Link tests are
not allowed after GCC_NO_EXECUTABLES.
make[3]: *** [configure-target-libiberty] Error 1
make[3]: Leaving directory
Martin Michlmayr writes:
I get the following failure while building gcc 4.2 on hppa:
checking for pid_t... no
checking for library containing strerror... configure: error: Link tests are
not allowed after GCC_NO_EXECUTABLES.
make[3]: *** [configure-target-libiberty] Error 1
make[3]:
Daniel Jacobowitz wrote:
...
Not even a single comment - shame on you both! :-) If this is the
solution we choose, can we make sure that there's at least a comment
explaining what's going on?
Totally agree. That was an *example patch*. Here is a bit updated, but
still an example of how
On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
(define_insn *arm_movqi_insn
[(set (match_operand:QI 0 nonimmediate_operand =r,r,r,Q)
(match_operand:QI 1 general_operand rI,K,m,+r))]
TARGET_ARM
( register_operand (operands[0], QImode)
||
On Jun 1, 2006, at 1:45 AM, Richard Earnshaw wrote:
The only problem I have with Mike's script is that it doesn't handle
runs with multiple multi-lib variants nicely.
Yeah, in the past, we drove the multilib pass from above as in
general we had to select different hardware for testing. I
I can't explain myself what is going on within this lines in
the .debug_frame section.
Context: AMD64 linux64 system. (Ubuntu)
Within the debug_frame section I find the following assembly instructions:
.byte0x4
.long.LCFI0-.LFB2
The distance between labels LCFI0 and LFB2 is
Hi!
Does anyone happen to know if it is possible to link
(and run) C code compiled with a powerpc-eabi targeted
gcc with C code compiled with a powerpc-linux targeted
gcc? The resulting program would be run on a PowerPC
Linux system (ELDK 4.0).
In this case, main() would be compiled by
Mark Mitchell wrote:
Mark Shinwell wrote:
As for the remaining problem, I suggest that we could:
(i) always return the hard frame pointer, and disable FP elimination in
the current function; or
(iii) ...the same as option (i), but allow targets to define another macro
that will cause the
On Thu, Jun 01, 2006 at 11:58:31AM +0530, Ranjit Mathew wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Faylor wrote:
On Wed, May 31, 2006 at 11:37:51PM +0200, FX Coudert wrote:
And I forgot to ask: who the heck is supposed to set USE_MINGW_MSYS?
(grep is soo sloow
My understanding is that: both are used to traverse BBs and the only
(potential )difference is the order of the traversal. 'FOR_EACH_BB'
traverses BBs throught the linked list order; 'for (i=0; in_basic_blocks;
i++){bb=BASIC_BLOCK(i);}' traverses accoring to the BB's index (because
The call from Linux-land to eabi-land would not need
to pass arguments nor return anything and nothing
would need to be shared between the two pieces of
code.
So basically you can replace the whole thing with sleep(1); and noone would be
any the wiser.
Paul
sean yang wrote on 06/01/06 14:44:
'for (i=0; in_basic_blocks; i++){bb=BASIC_BLOCK(i);}' traverses accoring to
the
BB's index (because BASIC_BLOCK(i)-index ==i)
The first form may take you to a NULL basic block. See expunge_block.
On 6/1/06, sean yang [EMAIL PROTECTED] wrote:
My understanding is that: both are used to traverse BBs and the only
(potential )difference is the order of the traversal. 'FOR_EACH_BB'
traverses BBs throught the linked list order; 'for (i=0; in_basic_blocks;
i++){bb=BASIC_BLOCK(i);}' traverses
I guess I should have also mentioned that the
resultant program will be run under gdb, with a script
setting breakpoints, running, examining variables,
etc.
--- Paul Brook [EMAIL PROTECTED] wrote:
The call from Linux-land to eabi-land would not
need
to pass arguments nor return anything and
Thanks. after reading expunge_block(), i am curious whether 'for (i=0;
in_basic_blocks; i++){} even works: from one hand, as routines such as
'compute_defs_uses_and_gen()' uses it, it should work; from the other hand,
from the code of expunge_block, BASIC_BLOCK[n_basic_blocks-1] may not be the
Please do. I'd welcome it (and scripts to generate html, to track
known issues, to trim log files, to drive things and do on)... I
think having a few different styles would be good, then people can
try them all out and see which ones they like and why. Anyway, for
me, it isn't yet
Whoops... I forgot to attach my fixes, for anyone that's interested.
--
Jim Lemke [EMAIL PROTECTED] Orillia, Ontario
--- dg-cmp-results.sh 2006/05/31 19:22:14 1.18
+++ dg-cmp-results.sh 2006/06/01 17:53:21
@@ -31,6 +31,16 @@ if test $# -ne 3 -o ! -f $2 -o ! -f $
exit 1
fi
+# Command
sean yang wrote on 06/01/06 15:28:
Thanks. after reading expunge_block(), i am curious whether 'for (i=0;
in_basic_blocks; i++){} even works.
That was my point: it doesn't, unless you can guarantee that the CFG has
been compacted.
Your approach is faster, esp. on Darwin / NetBSD.
The only advantages I see to mine is handling variants (Richard's patch
fixes that), verbosity control, and detail -- compare_tests only looks
at X?(PASS|FAIL).
Hmm.. another small point, FWIW.
Both the results files I used contained the
On Thu, 1 Jun 2006, James Lemke wrote:
Both the results files I used contained the following ssequence of
results:
PASS: gcc.c-torture/compile/930210-1.c (test for excess errors)
PASS: gcc.c-torture/compile/930210-1.c (test for excess errors)
FAIL: gcc.c-torture/compile/930210-1.c (test for
Both the results files I used contained the following ssequence of
results:
PASS: gcc.c-torture/compile/930210-1.c (test for excess errors)
PASS: gcc.c-torture/compile/930210-1.c (test for excess errors)
FAIL: gcc.c-torture/compile/930210-1.c (test for excess errors)
FAIL:
On Sun, 14 May 2006, Ranjit Mathew wrote:
Dave Yost points out that a cursory look at the main table
in:
http://gcc.gnu.org/releases.html
(which is linked-to from the main page) gives the impression
that 3.4.6 has been our last release. It is very easy to
miss the fine-print-like
On Thu, Jun 01, 2006 at 11:43:09PM +0200, Gerald Pfeifer wrote:
In the eyes of at least some, especially the dates for the old
releases in releases.html are of historical interest, so I'd be
quite hesitant to remove these.
I'm not sure I agree that it is easy to miss the statement on
Snapshot gcc-4.0-20060601 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060601/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Jun 1, 2006, at 11:32 AM, Ron McCall wrote:
Does anyone happen to know if it is possible to link
(and run) C code compiled with a powerpc-eabi targeted
gcc with C code compiled with a powerpc-linux targeted
gcc?
This is a linker question, we don't do linkers here. In particular,
the
Mark Shinwell wrote:
Option (i), which is in all but name the solution 5 approach [1] proposed
last year, means that the count == 0 case is elevated to the same level
of importance as the count 0 cases, in line with the use in
backtrace (). The problem with this is that on platforms where the
Geoff,
When building xplor with -shared-libgcc -whyload, I don't see any
explicit symbols being loaded from libgcc_s. However from
libxplorCmd.dylib, which has code called from xplor, I see...
/usr/lib/libgcc_s.1.dylib(unwind-dw2_s.o) loaded to resolve symbol:
__Unwind_Resume
I haven't found anything in the docs that I see that explains the
libiberty library. Can this be compiled without having to compile a whole
new compiler? I am running 3.4.6 and what to cross compile for a pdp-11. I
just want to compile the extra support and that's all.
Bill
I haven't found anything in the docs that I see that explains
the libiberty library.
You didn't find the libiberty documentation? It's separate from the
gcc documentation, but available on the gcc docs web page.
Can this be compiled without having to compile a whole new compiler?
Er,
- Original Message -
From: DJ Delorie [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 01, 2006 10:31 PM
Subject: Re: Libiberty
Please don't reply to me personally, use the mailing list.
Sorry I just pressed reply. You personal address must have been there.
Bill
--- Comment #56 from paul dot richard dot thomas at cea dot fr 2006-06-01
07:31 ---
Jerry,
Where are we with this one? Did you have time yet to automatize the testing?
It would be real nice to close it!
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
--- Comment #4 from mirko dot bruzzone at primeur dot com 2006-06-01 08:08
---
I tried to compile in another directory than the source directory and I
executed the make bootstrap...but nothing.
This is the report:
gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W
--- Comment #7 from paul dot richard dot thomas at cea dot fr 2006-06-01
08:17 ---
This is still the case; Is this a gfortran issue or a gcc one?
If I give the characters length, using any format, even the anonymous warning
goes away. In fact, any array expression that I have tried
: 3191.917
cache size : 512 KB
shows even more interesting results:
gcc version 3.4.6
vs.
gcc version 4.2.0 20060601 (experimental)
-fomit-frame-pointer -O -msse2 -mfpmath=sse
GCC 3.x performance:
./xmm_gcc
ALGORITHM NB REPSTIME MFLOPS
--- Comment #2 from mckinlay at redhat dot com 2006-06-01 11:07 ---
This rule is mentioned in the last paragraph of JVMS, S 5.4.4:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#75929
It is explicitly stated that this is checked during verification,
The testcase from PR target/27827 shows another problem, this time with
-ffast-math. The runtime performance of -ffast-math code drops for ~30%.
The problem could be traced down to reassociation tree pass, because the
performance jumps back when flag_unsafe_math_optimizations switch is disabled
$ cat tmp.c
unsigned athird (unsigned val)
{
return val / 3;
}
$ /home/etienne/projet/toolchain/bin/gcc -S -Os -o tmp.s -fomit-frame-pointer
-fverbose-asm tmp.c
$ cat tmp.s
.file tmp.c
# GNU C version 4.1.1 (i686-pc-linux-gnu)
# compiled by GNU C version 4.1.1.
# GGC
--- Comment #11 from jakub at gcc dot gnu dot org 2006-06-01 11:48 ---
Does the C++ FE need the exact decl after gimplification? If not, perhaps
as a workaround pushdecl_maybe_friend could together with duplicating DECL_UID
also populate a hash table and cp-gimplify.c would use that
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-06-01 12:09 ---
Similar(?) bug on ppc for trunk:
+===GNAT BUG DETECTED==+
| 4.2.0 20060601 (experimental) (SUSE Linux) (powerpc64-suse-linux-gnu) GCC
error
--- Comment #8 from dberlin at gcc dot gnu dot org 2006-06-01 12:22 ---
The SMT related stuff is a red herring.
Someone is not marking things for renaming when they should be.
The following patch will show that (it disables the used alone code).
Index: tree-ssa-operands.c
--- Comment #5 from bonzini at gnu dot org 2006-06-01 12:28 ---
Subject: Bug 25453
Author: bonzini
Date: Thu Jun 1 12:28:11 2006
New Revision: 114305
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114305
Log:
2006-06-01 Paolo Bonzini [EMAIL PROTECTED]
PR 25453
--- Comment #6 from bonzini at gnu dot org 2006-06-01 12:33 ---
documentation committed.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-01 12:40
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from WILLIAMPAUL dot PHILIBERT at telus dot com 2006-06-01
12:53 ---
Subject: RE: [4.1 only] fastjar is asking for makeinfo in gmake bootstrap
Sorry M. Pinski, I do not understand your comment. Do you mean fasjar is
removed from the pre-release and not in the
I get the following ICE when bootstrapping gcc 4.2 20060530 on alpha. 20060508
worked fine. I'm running delta right now and will send a test case when it's
done.
/build/buildd/gcc-snapshot-20060530/build/./gcc/xgcc
-B/build/buildd/gcc-snapshot-20060530/build/./gcc/
--- Comment #1 from tbm at cyrius dot com 2006-06-01 13:00 ---
3012:[EMAIL PROTECTED]: ~/tmp/delta/bin]
/home/tbm/tmp/gcc/20060530-alpha/gcc/xgcc -c
-O1 mini.c
3013:[EMAIL PROTECTED]: ~/tmp/delta/bin]
/home/tbm/tmp/gcc/20060530-alpha/gcc/xgcc -c
-O2 mini.c
mini.c: In function
--- Comment #2 from tbm at cyrius dot com 2006-06-01 13:01 ---
Created an attachment (id=11566)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11566action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
The C compiler generates wrong assembler code for functions with __attribute__
((interrupt (IRQ))). Link register lr in interrupt function is decremented
two times before it is loaded back to the program counter pc. It is decremented
at the beginning of interrupt routime (sub lr, lr, #4) and
I get the following ICE with gcc 4.2 20060508 and 20060530 on mipsel.
Actually, I get this with gcc 4.0 and 4.1 too. gcc 3.4 works.
sh-3.1# /usr/lib/gcc-snapshot/bin/gcc -c -O1 mini.c
mini.c: In function 'do_dror':
mini.c:56: internal compiler error: in expand_expr_real_1, at expr.c:6916
--- Comment #1 from tbm at cyrius dot com 2006-06-01 13:59 ---
Created an attachment (id=11567)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11567action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27861
/gcc/abuild/rguenther/obj/stage1-gcc/gnat1 -quiet -dumpbase g-os_lib.adb -O2 -W
-Wall -fPIC -g -mno-minimal-toc -gnatpg -gnatO g-os_lib.o g-os_lib.adb -o
/dev/null
+===GNAT BUG DETECTED==+
| 4.2.0 20060601 (experimental) (powerpc64-suse-linux-gnu
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-01 14:13 ---
Reproduces also with
/abuild/rguenther/obj/stage1-gcc/gnat1 -quiet -dumpbase g-os_lib.adb -O0
-gnatpg -gnatO g-os_lib.o g-os_lib.adb -o /dev/null
-fno-section-anchors fixes it.
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-01 14:17 ---
err, -O, not -O0 in previous comment. Obviously.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27862
--- Comment #3 from dje at gcc dot gnu dot org 2006-06-01 14:20 ---
dup
*** This bug has been marked as a duplicate of 27536 ***
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dje at gcc dot gnu dot org 2006-06-01 14:20 ---
*** Bug 27862 has been marked as a duplicate of this bug. ***
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from mark at codesourcery dot com 2006-06-01 14:59 ---
Subject: Re: [4.1 Regression] num_ssa_names inconsistent
or immediate use iterator wrong
jakub at gcc dot gnu dot org wrote:
--- Comment #11 from jakub at gcc dot gnu dot org 2006-06-01 11:48
---
Does
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-06-01 15:23 ---
(In reply to comment #1)
--with-headers with a combined build is not really a good thing.
--with-headers is required for cross compilers in order to build a working
libgcov. A working libgcov is required for
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 15:26 ---
There is nothing special about reassociation at all. In fact what you are
seeing is register allocator going funky. This what you get with x87.
--
pinskia at gcc dot gnu dot org changed:
What
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|tree-optimization |target
Keywords||build,
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||gcc-bugs at gcc dot gnu dot
|
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to work|
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2006-06-01 15:44
---
(In reply to comment #11)
Index: arith.c
===
--- arith.c (revision 114111)
+++ arith.c (working copy)
@@ -1133,8 +1133,10 @@
gcc -c -O2 e3.c
e3.c:1803: internal compiler error: in check_cfg, at haifa-sched.c:4615
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://www.suse.de/feedback for instructions.
--
Summary: [4.2 Regression] ICE in check_cfg, at
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-01 15:50 ---
Created an attachment (id=11569)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11569action=view)
testcase (unreduced)
Testcase. Reducing currently.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-01 15:57 ---
Reduced testcase:
long stack[100];
int main(int argc,char**argv,char **envp)
{
long *esp=stack;
static void* jarray[]={ KeyCtrlKV };
*++esp=(long)_loc0;
goto SetTermStruc;
_loc0:;
*++esp=(long)_loc1;
--- Comment #10 from whaley at cs dot utsa dot edu 2006-06-01 16:02 ---
Created an attachment (id=11571)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11571action=view)
Same benchmark, but with single precision timing included
Here's the same benchmark, but can time single as well
CCing myself so
I don't have to retype everything :)
gcc version 3.4.6
vs.
gcc version 4.2.0 20060601 (experimental)
-fomit-frame-pointer -O -msse2 -mfpmath=sse
There is a small performance drop on gcc-4.x, but nothing critical.
I can confirm, that code indeed runs 50% slower on 64bit athlon
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-01 16:28 ---
I can reproduce this with 4.2.0 Mon May 29 22:03:29 UTC 2006 (revision 114217M)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27858
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-01 17:14 ---
Confirmed, a little more reduced testcase:
typedef unsigned int uint32_t;
union double_union
{
double d;
uint32_t i[2];
};
int *_Jv_s2b (void);
int *_Jv_Balloc (int);
double _Jv_strtod_r (int *ptr, char *se,
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 17:21 ---
Confirmed, this is a RA issue.
Before register allocation:
(insn:HI 10 7 11 2 (set (reg:SI 63)
(const_int 3 [0x3])) 34 {*movsi_1} (nil)
(expr_list:REG_EQUIV (const_int 3 [0x3])
(nil)))
(insn:HI
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-01 17:24 ---
And yara gets this correct.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
FreePOOMA 2.4.1 fails to build on powerpc-linux with beginning with this patch:
http://gcc.gnu.org/viewcvs?view=revrev=114057
r114057 | rakdver | 2006-05-24 22:55:15 + (Wed, 24 May 2006)
Output with a minimized testcase:
elm3b145% /opt/gcc-nightly/trunk/bin/g++ -c -O2 poomabug.cc
--- Comment #1 from janis at gcc dot gnu dot org 2006-06-01 17:45 ---
Created an attachment (id=11574)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11574action=view)
minimized testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27865
--- Comment #5 from janis at gcc dot gnu dot org 2006-06-01 17:50 ---
A regression hunt using an alpha-linux cross compiler on powerpc64-linux with
the testcase mini.c identified the following patch:
http://gcc.gnu.org/viewcvs?view=revrev=113632
r113632 | sayle | 2006-05-08
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #4 from trini at kernel dot crashing dot org 2006-06-01 18:36
---
(In reply to comment #3)
Actually no, you have to use -fPIC to get this not to be optimized, otherwise
func will be bound locally which is not what you want.
Two things. First, that's a change in behavior
--- Comment #12 from whaley at cs dot utsa dot edu 2006-06-01 18:43 ---
Subject: Re: gcc 4 produces worse x87 code on all platforms than gcc 3
Uros,
gcc version 3.4.6
vs.
gcc version 4.2.0 20060601 (experimental)
-fomit-frame-pointer -O -msse2 -mfpmath=sse
There is a small
In the following program there is clearly a problem with the r = d
assignment. In most real programs such drastic case does not happen. However,
simple precision loss or worse things may occure.
gfortran -Wall should warn, but it does not deserve a default warning.
program test
double
| Hello,
|
| I found some unexpected behavior in valarray, couldn't find anything
| previous referencing it, and I thought that I'd write before
| (erroneously??) submitting a bug.
|
| Simple case: repeated application of operator==
|
| Silly example:
|
| std::valarrayint v1(100,1);
|
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-06-01 19:13 ---
(In reply to comment #3)
This is now fixed on mainline provided the user specifies -ffast-math.
There are some complications where imagpart(z*~z) can be non-zero, if
imagpart(z) is non-finite, such as an Inf or a
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-06-01 19:14
---
azuma% grep maxssiz /stand/system
tunable maxssiz 16777216
azuma% swapinfo
Kb Kb Kb PCT START/ Kb
TYPE AVAILUSEDFREE USED LIMIT RESERVE PRI NAME
dev 4194304
--- Comment #7 from pault at gcc dot gnu dot org 2006-06-01 19:19 ---
I think that this one can be declared well and truly gone for the time
being.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tkoenig at gcc dot gnu dot org 2006-06-01 19:24
---
Subject: Bug 27715
Author: tkoenig
Date: Thu Jun 1 19:23:56 2006
New Revision: 114317
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114317
Log:
2006-06-01 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #2 from tbm at cyrius dot com 2006-06-01 20:01 ---
I'm CCing Andreas Schwab since he apparently ported ffi to m68k. I noticed
that the part of the code that produces the error is within an ifdef
USE_LIBFFI, so possibly disabling ffi on m68k would allow it to compile. But
On Mon, 29 May 2006, Karl Berry wrote:
rms asked me to try systematize the Texinfo dir categories to match the
Free Software Directory where possible. So I hope you will be ok
with changing the gcc manuals to say
@dircategory Software development
instead of
@dircategory Programming
(and
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-06-01 21:09 ---
(In reply to comment #0)
In the following program there is clearly a problem with the r = d
assignment. In most real programs such drastic case does not happen. However,
simple precision loss or worse things may
It is really helpful to have a program which stops with
Fortran runtime error: Array reference out of bounds
when compiled with -fbounds-check. Because one has no idea where this happens.
Expected: At least crash so that one can do a backtrace in the debugger. Or
write out the file/line
--- Comment #4 from uweigand at gcc dot gnu dot org 2006-06-01 21:30
---
Yes, that makes sense -- in fact, it looks like altivec_vslw_v4sf can then be
removed as well. I'm currenly testing a patch to that effect ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27842
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-01 21:30 ---
Why not use gdb?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27868
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-01 21:31 ---
Thanks for taking care of this.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2006-06-01 21:37 ---
Gaby, I had a quick look and maybe it's just a trivial typo: the below seems
right to me and certainly fixes the testcase without regressions... What do you
think?
Thanks, Paolo.
//
Index:
--- Comment #3 from christophe dot jaillet at wanadoo dot fr 2006-06-01
21:37 ---
On my AMD Athlon and current HEAD and, I have other results, i.e. 2 or 3 times
FASTER :
(using your 19 bytes long 'aaa..' string)
stringfrom
lengthbuiltin library
(-O2)
--- Comment #15 from geoffk at gcc dot gnu dot org 2006-06-01 21:49 ---
After discussion with Mike, I don't think Andrew's fix is right either.
If varasm.c wants to be able to predict memory layout, then what it needs to do
is ensure that the memory layout is seen as a single unit by
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-01 21:50 ---
You set your break point on exit in gdb and run your program and then you get
the backtrace and look where the problem comes from, There is no magic going on
with -fbounds-check
Anyways this is a dup of bug 23375.
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-06-01 21:50 ---
*** Bug 27868 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from wilson at gcc dot gnu dot org 2006-06-01 22:36 ---
Subject: Bug 26483
Author: wilson
Date: Thu Jun 1 22:36:19 2006
New Revision: 114319
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114319
Log:
Fix broken denorm support.
PR libgcj/26483
* src/ia64/ffi.c
1 - 100 of 114 matches
Mail list logo
