--- Comment #12 from pinskia at gcc dot gnu dot org 2007-06-18 06:01
---
This no longer crashes for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-06-18 06:12
---
This is basically fixed by the pointer_plus except we still have some
combinable code (though this is not PRE's fault); see
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01996.html for how to fix that
issue.
--
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-18 06:16
---
*** Bug 30958 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 2007-06-18 06:16 ---
*** This bug has been marked as a duplicate of 30784 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2007-06-18 06:41 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-18 06:42 ---
There is a cast which confuses SCEV.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from stephan dot bergmann at sun dot com 2007-06-18 06:54
---
Re #3: http://gcc.gnu.org/onlinedocs/libstdc++/install.html#usage is not
relevant here. That info is about how client code can find libstdc++.so. This
issue is about how libstdc++.so can find the libraries
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-18 06:55
---
For -O1, it is even worse. I think we need to mark va_start/va_end as cannot
call clober their inputs at the tree level. This should at least fix the -O1
issue. It might also help code gen in other cases which
--- Comment #2 from redriver at korea dot ac dot kr 2007-06-18 07:40
---
(In reply to comment #1)
What version of GCC are you starting with?
This works for me on an i686-linux-gnu machine (a pentium 4D).
I think I found the problem. Previously, I use the gcc-3.2.2 to bootstrap the
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-18 07:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from patchapp at dberlin dot org 2007-06-18 08:00 ---
Subject: Bug number PR20373
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/2007-06/msg01216.html
--
--- Comment #3 from uros at gcc dot gnu dot org 2007-06-18 08:31 ---
Subject: Bug 32383
Author: uros
Date: Mon Jun 18 08:30:47 2007
New Revision: 125790
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125790
Log:
PR tree-optimization/32383
* targhooks.c
--- Comment #4 from ubizjak at gmail dot com 2007-06-18 08:33 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #29 from ubizjak at gmail dot com 2007-06-18 08:56 ---
Patch was committed to SVN, so closing as fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from patchapp at dberlin dot org 2007-06-18 09:55 ---
Subject: Bug number PR target/32369
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/2007-06/msg01225.html
--
--- Comment #25 from ubizjak at gmail dot com 2007-06-18 10:17 ---
(In reply to comment #24)
MEM[index: ivtmp.39, offset: 0x0fffc] = (MEM[index: ivtmp.35, offset:
0x0fffc] + 1 1) - MEM[index: ivtmp.39, offset: 0x0fffc];
We still get an offset of -4.
PR
--- Comment #2 from dorit at il dot ibm dot com 2007-06-18 11:03 ---
I see this in the vectorizer dump file (with mainline from a few days ago):
(compute_affine_dependence
(stmt_a =
D.3027_19 = p_7-a[D.3026_18])
(stmt_b =
p_7-a[D.3025_17] = D.3027_19)
Data ref a:
(Data Ref:
stmt:
--- Comment #4 from dorit at il dot ibm dot com 2007-06-18 11:08 ---
I see this in the vectorizer dump file (with mainline from a few days ago):
(compute_affine_dependence
(stmt_a =
D.1423_50 = (*a_49(D))[D.1422_48])
(stmt_b =
(*a_49(D))[D.1420_51] = D.1425_54)
Data ref a:
(Data
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-18 11:26 ---
Execution times (seconds)
preprocessing : 0.09 ( 0%) usr 0.07 (20%) sys 0.18 ( 0%) wall
376 kB ( 1%) ggc
parser: 0.26 ( 0%) usr 0.12 (34%) sys 0.45 ( 0%) wall
33574 kB
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
|
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-06-18 11:28 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
In tree-ssa-math-opts.c we already had a pass to cse sin and cos. The new
reciprocal sqrt pass is mechanically similar to that one. It does a linear
scan over the CFG applying these peephole transformations. This new pass
should not be doing a separate IL scan to do its job.
Perhaps it would
--- Comment #25 from dnovillo at gcc dot gnu dot org 2007-06-18 12:30
---
Fixed symptoms with http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01081.html.
Real fix still being discussed.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from zadeck at naturalbridge dot com 2007-06-18 12:33
---
I believe that the failure is due to a an insn illegally sharing with a
reg_equal note. Insn 8 is modified in regmove. When this happens, the
reg_equal note in insn 22 magically changes. That reg_equal note was
--- Comment #2 from zadeck at naturalbridge dot com 2007-06-18 12:35
---
s/cse/cse1/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32372
--- Comment #7 from patchapp at dberlin dot org 2007-06-18 12:40 ---
Subject: Bug number PR target/32335
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/2007-06/msg01233.html
--
--- Comment #3 from zadeck at naturalbridge dot com 2007-06-18 13:18
---
Subject: Re: [frv] macro DF_LIVE_IN passed 2 arguments,
but takes just 1
:reviewmail:
patchapp at dberlin dot org wrote:
--- Comment #2 from patchapp at dberlin dot org 2007-06-18 09:55 ---
Subject:
--- Comment #8 from aesok at gcc dot gnu dot org 2007-06-18 13:33 ---
Im working on patch for avr target.
Anatoly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-18 13:56 ---
All three transformations are done at different stages of the optimization
pipeline due to various reasons.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32390
--- Comment #2 from dnovillo at google dot com 2007-06-18 14:00 ---
Subject: Re: tree-ssa-math-opts.c performs too
many IL scans
On 6/18/07 9:56 AM, rguenth at gcc dot gnu dot org wrote:
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-18 13:56
---
All three
This bug occurs on gfortran 4.1 and 4.2 .
I think it is not a gfortran specific bug; I checked g77 and g95 on gcc 3.4.6..
I had compiled a legacy fortran77 code and foud a bug;
$ gfortran -o TMalign TMalign.f
$ ./TMalign 1aquA.pdb 1avaC.pdb | grep ^Ali
Aligned length= 89, RMSD=
--- Comment #2 from matze at braunis dot de 2007-06-18 14:17 ---
Why don't you turn on dataflow computation to get the warning even with -O0?
-O0 is typically used for developing/debugging, so as a user I want to see all
possible warnings...
--
--- Comment #1 from sunjoong at gmail dot com 2007-06-18 14:18 ---
Created an attachment (id=13727)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13727action=view)
A legacy fortran77 program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
--- Comment #2 from sunjoong at gmail dot com 2007-06-18 14:19 ---
Created an attachment (id=13728)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13728action=view)
A input data file of TMalign
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
--- Comment #3 from sunjoong at gmail dot com 2007-06-18 14:20 ---
Created an attachment (id=13729)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13729action=view)
A input data file of TMalign
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
Paolo Bonzini wrote:
That said, there is a whole bunch of applications that would kill for
-mrecip,
even for 11bit ones. Games are one of them, for sure ;)
What about -mrecip=0/1/2 for the number of NR steps? Or would two steps be
slower than divss?
I was thinking of adding this as a
This program runs Ok on the Macintosh versions of gfortran. It runs Ok on the
i386-pc-mingw32 version of gfortran using -g, but fails using -O3. It always
fails on the cygwin version of gfortran -
gfortran -o g95Test01 g95Test01.f
./g95Test01
1
lower triangular matrix with 3 rows
row 1
--- Comment #1 from dir at lanl dot gov 2007-06-18 14:48 ---
Here are the mingw32 results -
$ gfortran -g -o g95Test01 g95Test01.f
[EMAIL PROTECTED] ~/tests
$ g95Test01
1
lower triangular matrix with 3 rows
row 10.8000E+01
row 20.9000E+01 0.1000E+02
row 3
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-18 14:52 ---
Compiling your code with g95 gives a lot of warnings. You should probably check
the use of the different subroutines.
In file pr32393.f:189
subroutine clect2
1
In file pr32393.f:155
--- Comment #1 from hjl at lucon dot org 2007-06-18 15:02 ---
Fixed by
http://gcc.gnu.org/ml/gcc-cvs/2007-06/msg00569.html
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-06-18 15:03 ---
Initial suggestion, see:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01068.html
Richard's remark:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01224.html
Two NR steps don't make sense, they wouldn't improve
--- Comment #3 from dir at lanl dot gov 2007-06-18 15:05 ---
The only subroutine actually used is prmx. The rest are dummies to make the
linker happy. With g95, you get the correct results with -g and incorrect
results with -O3 -
[QuadG5:~/junk] dir% g95 -O3 -d8 -fstatic
--- Comment #4 from sunjoong at gmail dot com 2007-06-18 15:08 ---
Thank you, Tobias
I had missunderstood the default optimization level for gfortran
but the issue exists, I think.
I had traced side effects of optimization levels for the legacy program;
-O0 level and -O1 level
--- Comment #4 from dominiq at lps dot ens dot fr 2007-06-18 15:29 ---
The only subroutine actually used is prmx. The rest are dummies to make the
linker happy.
One thing which is obviously wrong is that 't' is declared as integer in vr2,
but is real in the calling program and in
--- Comment #5 from dominiq at lps dot ens dot fr 2007-06-18 15:38 ---
I did not make as many tests as Tobias, but it works for me on PPC with g77,
xlf, g95, and gfortran.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32391
or c
compiler?
2007/6/19, Tobias Burnus [EMAIL PROTECTED]:
As said: It works here with 4.1.3 20070521, 4.2.1 20070604 and 20070618,
4.3.0 20070618. It also work with my g95, Intel Fortran and sunf95
compilers. In all cases I get:
Aligned length= 91, RMSD= 6.35, TM-score=0.24762, ID=0.024
--- Comment #5 from burnus at gcc dot gnu dot org 2007-06-18 16:15 ---
Now I don't know how the compiler is supposed to behave when there is a
mismatch between the arguments in the subroutines and their call.
Well it is always said that it may do anything such as starting the third
--
langton at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |langton at gcc dot gnu dot
|dot org
)
and with FX's
Target: i386-pc-linux-gnu
gcc version 4.3.0 20070618 (experimental)
Interestingly, it works on x86_64-unknown-linux-gnu even with -m32.
(I somehow fail to run FX's i386 compiler on x86-64.)
I think this could be a middle-end or target problem as it is that target
dependent
--- Comment #3 from zadeck at gcc dot gnu dot org 2007-06-18 16:47 ---
Subject: Bug 32355
Author: zadeck
Date: Mon Jun 18 16:47:05 2007
New Revision: 125812
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125812
Log:
2007-06-18 Kenneth Zadeck [EMAIL PROTECTED]
PR
--- Comment #4 from zadeck at naturalbridge dot com 2007-06-18 16:48
---
Subject: Re: [4.3 Regression] ICE in df_lr_verify_transfer_functions,
at df-problems.c:1924
committed as revision 125812
zadeck at naturalbridge dot com wrote:
--- Comment #1 from zadeck at naturalbridge
--- Comment #5 from zadeck at naturalbridge dot com 2007-06-18 16:50
---
fixed,revision 125812
--
zadeck at naturalbridge dot com changed:
What|Removed |Added
At least one of these three calls do not work properly in deferred rescanning
mode.
delete_trivially_dead_insns
rebuild_jump_labels
cleanup_cfg
The most likely cause of the failure is that we are not keeping enough
information around in the deferred scanning mode to properly track all of the
gcc-4.1 produces a warning for the following testcase.
(testcase uses headers from boost-1.34.0).
$ cat multi_index_test.cpp
#include boost/multi_index_container.hpp
#include boost/multi_index/ordered_index.hpp
#include boost/multi_index/identity.hpp
#include boost/multi_index/member.hpp
--- Comment #1 from pluto at agmk dot net 2007-06-18 17:25 ---
Created an attachment (id=13730)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13730action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32395
--- Comment #8 from sunjoong at gmail dot com 2007-06-18 17:26 ---
I checked which part of TMalign.f make optimizaton wrong;
In DP subroutine,
DO j=1,NSEQ2
DO i=1,NSEQ1
D=VAL(i-1,j-1)+SCORE(i,j)
H=VAL(i-1,j)
if(DIR(i-1,j))H=H+GAP_OPEN
--- Comment #9 from daney at gcc dot gnu dot org 2007-06-18 17:36 ---
Subject: Bug 32313
Author: daney
Date: Mon Jun 18 17:36:42 2007
New Revision: 125818
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125818
Log:
PR target/32313
* config/mips/mips.c
--- Comment #3 from ubizjak at gmail dot com 2007-06-18 17:40 ---
(In reply to comment #2)
We need a better explanation than this. Uros agreed to summarize the
IRC discussion to close this issue. It'd be useful if we keep that same
discussion on the source code itself.
The need
--- Comment #10 from daney at gcc dot gnu dot org 2007-06-18 17:41 ---
The ability to bootstrap is fixed by the patch. There are other dataflow
regressions that will be fixed by follow up patches.
--
daney at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from dir at lanl dot gov 2007-06-18 18:13 ---
Now I don't know how the compiler is supposed to behave when there is a
mismatch between the arguments in the subroutines and their call.
I do - since the beginning of FORTRAN, well, at least since FORTRAN 2, it
simply
--- Comment #9 from sunjoong at gmail dot com 2007-06-18 18:31 ---
I cut the bellow and made a new subroutine,
then another part did not change on '-O0' and '-O1';
D=VAL(i-1,j-1)+SCORE(i,j)
H=VAL(i-1,j)
if(DIR(i-1,j))H=H+GAP_OPEN
V=VAL(i,j-1)
--- Comment #10 from kargl at gcc dot gnu dot org 2007-06-18 18:36 ---
There are literal hundreds of warning given by ftnchek, and there
appears to be an array bounds problem.
troutmask:sgk[231] gfc4x -o z -O -fbounds-check TMalign.f
troutmask:sgk[232] ./z 1aquA.pdb 1avaC.pdb | grep
--- Comment #7 from dominiq at lps dot ens dot fr 2007-06-18 18:44 ---
I do ...
I am not in the position to argue about what f90 compilers are supposed to do
with the original code. I just attach a modified one I hope is valid: g95 does
not complain and gives:
karma] f90/bug% bg95
--- Comment #8 from dominiq at lps dot ens dot fr 2007-06-18 18:46 ---
Created an attachment (id=13731)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13731action=view)
valid test case(?)
I have removed the dummy subroutines and type mismatch.
--
--- Comment #11 from sunjoong at gmail dot com 2007-06-18 18:47 ---
Yes, I agree that program is not beautiful
and I know the the array 'w' of 'u3b' subroutine problem;
I think the author of u3b use w(1) as pointer.
However,
the wrong generation of optimized code occurs in 'DP'
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-06-18 19:02
---
Updated patch.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from kargl at gcc dot gnu dot org 2007-06-18 19:16 ---
(In reply to comment #11)
Yes, I agree that program is not beautiful
and I know the the array 'w' of 'u3b' subroutine problem;
I think the author of u3b use w(1) as pointer.
Change the 1 to *.
However,
the
--- Comment #11 from daney at gcc dot gnu dot org 2007-06-18 19:35 ---
Subject: Bug 32313
Author: daney
Date: Mon Jun 18 19:35:05 2007
New Revision: 125824
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125824
Log:
Revert:
2007-06-18 David Daney [EMAIL
--- Comment #12 from daney at gcc dot gnu dot org 2007-06-18 19:35 ---
That fix was incorrect. Sorry.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from daney at gcc dot gnu dot org 2007-06-18 19:39 ---
This is the same problem as:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01165.html
I am currently bootstrapping the patch in that e-mail thread and will probably
commit that version.
--
--- Comment #7 from spark at gcc dot gnu dot org 2007-06-18 20:02 ---
Subject: Bug 32339
Author: spark
Date: Mon Jun 18 20:02:33 2007
New Revision: 125825
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125825
Log:
gcc/ChangeLog:
2007-06-18 Seongbae Park [EMAIL PROTECTED]
--- Comment #13 from sunjoong at gmail dot com 2007-06-18 20:24 ---
The '-ffloat-store' option works! Thank you.
However that gave me some quenstions;
Is that feature or bug?
There is many floating point operations of course.
Why the only one specific resion make problem?
Hi,
I need experts to shed light on C/C++ data type size inconsistencies when
running 64-bit and 32-bit ELF executables compiled by GNU/GCC g++/gcc
Following are results of C/C++ data type size from code cout data
type sizeof(data type) endl :
| 32-bit | 64-bit
--- Comment #14 from kargl at gcc dot gnu dot org 2007-06-18 20:47 ---
(In reply to comment #13)
The '-ffloat-store' option works! Thank you.
However that gave me some quenstions;
Is that feature or bug?
It is a 'feature' of the i386 class of cpu. See PR 323 for
details.
--- Comment #3 from spark at gcc dot gnu dot org 2007-06-18 20:49 ---
Subject: Bug 32321
Author: spark
Date: Mon Jun 18 20:49:23 2007
New Revision: 125827
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125827
Log:
2007-06-18 Seongbae Park [EMAIL PROTECTED]
PR
In altivec load/store instructions (lvx, stvx, ...) and lsvl/lsvr, when address
is supplied as pointer + well-known constant, gcc always calculates the actual
address in scalar unit and does not use sum in those instructions (puts 0 as
index). This slows-down some simple altivec loops.
Sample
--- Comment #9 from burnus at gcc dot gnu dot org 2007-06-18 21:04 ---
valid test case(?)
I have removed the dummy subroutines and type mismatch.
Still not fully valid as NAG f95 complains
Error: yyy.f: Argument IVG (no. 2) in reference to VR2 from MAIN is not an
array
[...]
However,
--- Comment #1 from sparky at pld-linux dot org 2007-06-18 21:11 ---
Created an attachment (id=13732)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13732action=view)
simple testcase and benchmark
on 1.3GHz iBook built without USE_ASM runs in 2.335s, with USE_ASM runs in
1.815s
--- Comment #2 from eweddington at cso dot atmel dot com 2007-06-18 22:00
---
Created an attachment (id=13733)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13733action=view)
Patch to fix bug, written by Anatoly Sokolov
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31331
--- Comment #3 from eweddington at cso dot atmel dot com 2007-06-18 22:01
---
The attached patch, written by Anatoly Sokolov, fixes the bug.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #3 from simonb at gcc dot gnu dot org 2007-06-18 22:09 ---
Subject: Bug 31923
Author: simonb
Date: Mon Jun 18 22:09:14 2007
New Revision: 125829
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125829
Log:
gcc/cp/ChangeLog
2007-06-15 Simon Baldwin [EMAIL PROTECTED]
--- Comment #2 from uros at gcc dot gnu dot org 2007-06-18 22:33 ---
Subject: Bug 32389
Author: uros
Date: Mon Jun 18 22:32:56 2007
New Revision: 125830
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125830
Log:
PR target/32389
* config/i386/i386.h (enum
--- Comment #3 from ubizjak at gmail dot com 2007-06-18 22:35 ---
Fixed in mainline.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #4 from ubizjak at gmail dot com 2007-06-18 22:36 ---
(In reply to comment #3)
I don't know if this is data flow related any more, due to the reporting of PR
32389.
No, this one is caused by dataflow.
--
ubizjak at gmail dot com changed:
What|Removed
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-18 22:49 ---
John,
5.1
.many snips.
If a specification-expr involves a reference to a specification function
(7.1.6.2), the expression is considered to be a nonconstant expression. If the
data object being declared
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-18 23:04 ---
Subject: Bug 20082
Author: pault
Date: Mon Jun 18 23:04:28 2007
New Revision: 125831
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125831
Log:
2007-06-19 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2007-06-18 23:04 ---
Subject: Bug 20863
Author: pault
Date: Mon Jun 18 23:04:28 2007
New Revision: 125831
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125831
Log:
2007-06-19 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-18 23:04 ---
Subject: Bug 32236
Author: pault
Date: Mon Jun 18 23:04:28 2007
New Revision: 125831
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125831
Log:
2007-06-19 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-18 23:07 ---
Subject: Bug 20882
Author: pault
Date: Mon Jun 18 23:07:32 2007
New Revision: 125832
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125832
Log:
2007-06-19 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #6 from pault at gcc dot gnu dot org 2007-06-18 23:08 ---
Fixed on trunk
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20863
--- Comment #4 from pault at gcc dot gnu dot org 2007-06-18 23:09 ---
Fixed on trunk
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20882
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-18 23:10 ---
Fixed on trunk
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32236
Hi Paul,
In your recent checkin:
http://gcc.gnu.org/viewcvs?view=revrevision=125831
You list PR fortran/20082 as one of the bugs fixed.
PR 20082 is a target bug for the AVR target and was resolved as invalid. So
it looks like you have the wrong PR number in your ChangeLog.
Thanks,
Eric
this C code line
{(((Cyg_libm_ieee_double_shape_type *)x)-parts.msw) =
(hx0x800f)|(k20); return x;}
causes this assembler code to be generated:
bic r3, ip, #2130706432
bic r3, r3, #15728640
ldmia sp, {r0-r1}
orr r3, r3, r2, asl #20
str r3, [r5, #0]
b .L6
The ldmia
--- Comment #8 from John dot Harper at mcs dot vuw dot ac dot nz
2007-06-19 01:13 ---
Subject: Re: Pure function not allowed in specification
expression
On Tue, 18 Jun 2007, pault at gcc dot gnu dot org wrote:
Date: 18 Jun 2007 22:49:37 -
From: pault at gcc dot gnu dot org
checking for hppa64-hp-hpux11.11-gcc... /test/gnu/gcc/objdir/./gcc/xgcc
-B/test/
gnu/gcc/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/bin/
-B/opt
/gnu64/gcc/gcc-4.3.0/hppa64-hp-hpux11.11/lib/ -isystem
/opt/gnu64/gcc/gcc-4.3.0/
hppa64-hp-hpux11.11/include -isystem
--- Comment #1 from danglin at gcc dot gnu dot org 2007-06-19 02:39 ---
This appears to be another problem in handling return pointer:
0x403e5644 lshift_significand+148:extrd,u ret0,63,32,rp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32398
--- Comment #9 from kargl at gcc dot gnu dot org 2007-06-19 03:50 ---
John,
With your acknowledgment of pault's comment, I think this
can be closed. Thanks for the reports. These types of
potential corner cases keep us on our toes.
--
kargl at gcc dot gnu dot org changed:
--- Comment #8 from spark at gcc dot gnu dot org 2007-06-19 04:30 ---
(In reply to comment #7)
Subject: Bug 32339
Author: spark
Date: Mon Jun 18 20:02:33 2007
New Revision: 125825
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125825
Log:
gcc/ChangeLog:
2007-06-18
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-19 04:38 ---
Fixed.
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
1 - 100 of 103 matches
Mail list logo
