--- Comment #17 from burnus at gcc dot gnu dot org 2010-01-04 21:13 ---
FIXED. Thanks Göran for the suggestion! If you want to try, I can send you the
gcc.pot file of the current 4.5 trunk (or do "cd $GCC_build_dir/gcc; make
gcc.pot" to create ./po/gcc.pot yourself.)
See also http://gcc
--- Comment #2 from bergner at gcc dot gnu dot org 2010-01-04 21:57 ---
The assembly looks different and doesn't error with today's trunk (revision
155629). I'll try with the revision Janis pointed out and see if it really is
fixed or is just latent again.
--
http://gcc.gnu.org/bug
--- Comment #3 from janis at gcc dot gnu dot org 2010-01-04 22:12 ---
I get the same error with mainline built today. I'm using a compiler that
defaults to -m32; it works fine with -m64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42427
--- Comment #9 from hjl dot tools at gmail dot com 2010-01-04 22:36 ---
(In reply to comment #8)
> The testcase failed at run-time. See PR 42602
>
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00187.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42517
--- Comment #5 from hjl dot tools at gmail dot com 2010-01-04 22:37 ---
(In reply to comment #4)
> Now I got
>
> At line 14 of file
> /export/gnu/import/svn/gcc-test/src-trunk/libgomp/testsuite/libgomp.fortran/recursion1.f90
> Fortran runtime error: Recursive call to nonrecursive proced
http://gcc.gnu.org/ml/gcc/2009-12/msg00169.html
From: Jianzhang Peng
I unroll the following code one times in a gimpile pass.
for(i=0; i< N ; i++)
a[i] = b[i] + c[i];
And then I create the loops's ddg using build_intra_loop_deps ( ) in
an RTL pass;
I found the data dependence information: i
--- Comment #4 from bergner at gcc dot gnu dot org 2010-01-04 23:05 ---
Ahh, yes, you are correct. I can confirm the bogus assembly code. I'll
investigate.
--
bergner at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #50 from rguenth at gcc dot gnu dot org 2010-01-04 23:11
---
ira_traverse_loop_tree and its callee process_bb_node_for_cost accounts for
nearly as much time as reload takes on hashes.c.
Btw, I find valgrind --tool=callgrind together with kcachegrind a better tool
for benchm
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-04 23:25 ---
See http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00463.html for a half-way
working
patch. Somebody needs to dive into var-tracking.c and fix the fallout.
--
rguenth at gcc dot gnu dot org changed:
Wh
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords||alias, mi
The test program writes 3 values of a discriminated record to a stream
('Output) and then reads them back ('Input).
It then uses 'Write and 'Read for a single value.
No problem arises with 32-bit compilations, or with 64-bit compilations with
-O0.
With -O1 or -O2, the values read back are incorre
--- Comment #1 from simon at pushface dot org 2010-01-04 23:34 ---
Created an attachment (id=19469)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19469&action=view)
Reproducer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42618
--- Comment #1 from ramana at gcc dot gnu dot org 2010-01-04 23:44 ---
For completeness the options are with -mthumb -Os -march=armv5te ?
With trunk I see a size of 52 bytes and this code.
.type test, %function
test:
push{r4, r5, r6, r7, lr}
sub sp,
--- Comment #3 from kkojima at gcc dot gnu dot org 2010-01-04 23:47 ---
Subject: Bug 42316
Author: kkojima
Date: Mon Jan 4 23:46:56 2010
New Revision: 155634
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155634
Log:
PR target/42316
* configure.ac (PICFLAG): Use
--- Comment #4 from kkojima at gcc dot gnu dot org 2010-01-04 23:49 ---
Fixed.
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from yuri at rawbw dot com 2010-01-04 23:57 ---
Subject: Re: Segmentation fault when ecj.jar is run as a
binary compiled by gcj
gerald at pfeifer dot com wrote:
> --- Comment #6 from gerald at pfeifer dot com 2010-01-03 13:10 ---
> Would you mind trying again w
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2010-01-05 00:19
---
Regarding "There's nothing funny or weird about the compile line folks", well,
actually, it was really needed. Turns out it doesn't fail without "-g", which
is why I didn't see it.
--
fxcoudert at gcc dot gnu
--- Comment #2 from janis at gcc dot gnu dot org 2010-01-05 00:53 ---
Currently the compiler explicitly allows "-mvsx -mno-altivec". If those
options are used together, should vsx and altivec both be turned on, or both
turned off?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4241
--- Comment #8 from bkoz at gcc dot gnu dot org 2010-01-05 01:10 ---
Glad you can reproduce now. Sorry I was so vague before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42346
--- Comment #10 from jlpoole at pon dot net 2010-01-05 02:31 ---
http://gcc.gnu.org/install/finalinstall.html has:
v
...
We strongly recommend to install into a target directory where there is no
previous version of GCC present.
...
Installation into a temporary staging area or into
--- Comment #11 from jlpoole at pon dot net 2010-01-05 02:34 ---
For the record:
plug build # ls -la config.log
-rw-r--r-- 1 root root 36708 2010-01-03 17:37 config.log
plug build # head config.log
This file contains any messages produced by compilers while
running configure, to aid debu
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2010-01-05 03:01
---
I have read through the links given by Dave. My take is that we have some
implementation dependent, non portable, behaviour in linkers. Now that we know
we have this inconsistency, the question is do we want to
--- Comment #4 from adam at consulting dot net dot nz 2010-01-05 04:17
---
/* Workaround discovered! */
void test_int_vectors_containing_fp_data_using_local_reg_var_overlay() {
//create local register variables of the required floating point type
//(for the same global register vari
--- Comment #1 from kargl at gcc dot gnu dot org 2010-01-05 05:49 ---
(In reply to comment #0)
> [forwarded from http://bugs.debian.org/501560]
>
> "gfortran documentation lacks any kind of info about how to create a module
> .mod file. It should be quite easy to indicate that the stand
--- Comment #11 from burnus at gcc dot gnu dot org 2010-01-05 07:19 ---
Subject: Bug 41872
Author: burnus
Date: Tue Jan 5 07:19:30 2010
New Revision: 155639
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155639
Log:
2010-01-05 Tobias Burnus
PR fortran/41872
101 - 126 of 126 matches
Mail list logo
