--- Comment #9 from bonzini at gnu dot org 2007-12-18 08:05 ---
Uros mentioned offlist that he wanted to hijack fwprop to always propagate
stack slots into instructions.
It would be a relatively useful piece of infrastructure to have a flag in MEMs
that marks on-stack MEMs, because
--- Comment #10 from ebotcazou at gcc dot gnu dot org 2007-12-18 08:10
---
It would be a relatively useful piece of infrastructure to have a flag in MEMs
that marks on-stack MEMs, because other MEMs definitely must not be propagated
blindly.
Depending on your needs, MEM_NOTRAP_P
--- Comment #20 from bonzini at gnu dot org 2007-12-18 08:35 ---
Eric, would you please take a look at my counter-proposal and commit it if it
works?
--
bonzini at gnu dot org changed:
What|Removed |Added
This test was fine with revision 130991 but broken with mainline now. This is
what I get now :
[~] gcc pr26943-2.c -lgomp
[~] ./a.out
zsh: abort ./a.out
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc/4.3.0
--- Comment #1 from jakub at gcc dot gnu dot org 2007-12-18 10:52 ---
This test relies on being compiled wit -fopenmp (as a bunch of other tests do).
Why are you compiling it without it?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-18 11:39 ---
IMHO it can validly print 7, 14, 21 or 28. See OpenMP 2.5, section 2.5.2:
The method of scheduling the structured blocks among threads in the team is
implementation defined.
Also, data sharing clause is sections
--- Comment #12 from hubicka at gcc dot gnu dot org 2007-12-18 11:41
---
But I wonder what would be the best way to add the PHI nodes. We really
shouldn't do mark_sym_for_renaming on underlying decl, perhaps create a dummy
decl, let intossa create PHIs etc. for it, then change the
--- Comment #1 from ludovic at ludovic-brenta dot org 2007-12-18 12:10
---
Actually, the declaration of x2 is illegal; GNAT is correct in rejecting it.
The declaration of T3 is legal and incorrectly rejected. The error messages
are:
gnatmake -gnat05 pak1-pak3.ads
gcc-4.1 -c -gnat05
--- Comment #47 from steven at gcc dot gnu dot org 2007-12-18 13:46 ---
(From update of attachment 10017)
Patch is obsolete because it was commited.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ubizjak at gmail dot com 2007-12-18 13:47 ---
Generated code for a similar example is just plain stupid:
--cut here--
int test(long long a, long long b)
{
return a * b;
}
--cut here--
gcc -O3:
test:
pushl %ebp
movl%esp, %ebp
--- Comment #6 from aph at gcc dot gnu dot org 2007-12-18 14:06 ---
Subject: Bug 27643
Author: aph
Date: Tue Dec 18 14:06:15 2007
New Revision: 131036
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131036
Log:
2007-12-18 Andrew Haley [EMAIL PROTECTED]
PR java/27643
-20071218/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/./libgomp/.libs:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/gcc:.:/var/pisi/gcc-4.3_pre20071218-31/work/gcc-4.3-20071218/build-default-i686-pc-linux-gnu/i686-pc-linux-gnu/./libgomp/.libs:/var/pisi/gcc
Default assert.h on Tru64 5.1 has an include guard around the whole include in
format of:
#ifndef __ASSERT_H_
#define __ASSERT_H_
... rest of the code ...
#endif /* __ASSERT_H_ */
This leads to a behavior different from the one described in the standard,
where assert.h is claimed to be the
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-18 14:30 ---
On i386 you need also -march=i486 or higher, i386 doesn't have instructions
for atomic stuff.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34519
--- Comment #4 from ismail at pardus dot org dot tr 2007-12-18 14:39
---
[~] gcc -fopenmp -march=i486 pr26943-2.c -lgomp
[~] ./a.out
[~]
works fine like this, I don't know why it fails in the tests. Hmm wonder if
--with-cpu=generic could affect this? This is a 4 CPU Xeon machine
--- Comment #7 from dominiq at lps dot ens dot fr 2007-12-18 15:11 ---
The patch in comment #6 fix the problem without regression on PPC/Intel
Darwin9.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34413
--- Comment #4 from rask at gcc dot gnu dot org 2007-12-18 15:31 ---
Subject: Bug 33474
Author: rask
Date: Tue Dec 18 15:30:57 2007
New Revision: 131037
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131037
Log:
PR target/33474
* config/bfin/bfin.c
I am using GCC (4.3 - 20071130 snapshot) and getting the null pointer
exception.
Exception in thread [EMAIL PROTECTED]
java.lang.CloneNotSupportedExcept
ion
at java.lang.Object.clone
at gnu.javax.net.ssl.provider.SSLEngineImpl.setEnabledProtocols
--
Summary: SSLEngine - Clone
--- Comment #5 from rask at gcc dot gnu dot org 2007-12-18 15:58 ---
Fixed with revision 131037.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from bonzini at gnu dot org 2007-12-18 16:01 ---
The problem in comment #11 is that GCC generates a widening multiply, and
cannot remove the DImode operations until after register allocation (!). While
the root cause is a deficiency in RTL-level DCE, I suggest filing a
--- Comment #13 from jakub at gcc dot gnu dot org 2007-12-18 16:39 ---
I think tree level does the right thing, TER fixes this up and expand_expr
is called with
return (int) (b * a)
Later on expand_expr is called with
mult_expr 0x2e9032c0
type integer_type 0x2e937840 long
For
int test(long long a, long long b)
{
return a * b;
}
GCC generates a widening multiply, and cannot remove the DImode operations
until after register allocation. This causes unnecessary splits.
This could be fixed on the tree level by folding to (int)a * (int)b, or
alternatively in
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #14 from bonzini at gnu dot org 2007-12-18 16:50 ---
The bug with 64*64-32 multiplication is now PR34522.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236
--- Comment #1 from bonzini at gnu dot org 2007-12-18 16:58 ---
Prototype untested patch. Produces
movl12(%esp), %eax
imull 4(%esp), %eax
ret
on the testcase.
Index: expr.c
===
--- expr.c
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2007-12-18
17:14 ---
Andreas,
Can't we duplicate the existing code in darwin.S, darwin_closure.S,
ffi_darwin.c and sysv.S and wrapper it with a test for __powerpc64__ as a
starting point. I think if we at least get
--- Comment #1 from csm at gnu dot org 2007-12-18 17:45 ---
A CloneNotSupportedException is not a null pointer exception.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34521
checking whether sigaltstack is declared... yes
checking for struct tms... yes
checking for clock_t... yes
checking for .preinit_array/.init_array/.fini_array support... no
checking if mkdir takes one argument... no
Unknown CPU used in --with-cpu=arm926ejs
make[2]: *** [configure-stage1-gcc] Error
--- Comment #2 from csm at gnu dot org 2007-12-18 18:08 ---
Created an attachment (id=14790)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14790action=view)
Test case
Can you try running this test program in your setup? We should confirm first
that this isn't a regression in GCJ
--- Comment #15 from ubizjak at gmail dot com 2007-12-18 18:20 ---
(In reply to comment #7)
mull%ebx
leal(%ecx,%edx), %esi ; what the heck, a simple addl could do!
movl%esi, %edx
Something disturbs RA to emit two DImode moves:
(insn:HI 10 36
--- Comment #16 from ubizjak at gmail dot com 2007-12-18 18:33 ---
(In reply to comment #15)
Note two moves [(insn 36) and (insn 37)] around (insn 12).
Bah. This is the correct sequence, around (insn 10) that seems to be the root
of all problems:
(insn:HI 9 8 36 2 m.c:2 (parallel [
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-12-18 18:51 ---
I do not see a way how to fix this in 4.3, other than disabling vectorizer when
parallelization is enabled, or vice versa.
--
rakdver at gcc dot gnu dot org changed:
What|Removed
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #13 from hubicka at gcc dot gnu dot org 2007-12-18 18:54
---
Sorry, my last comment was about different inliner issue that seems to be gone
now. I guess easiest way around would be to initialize to 0 at the beggining
of inlined function body? This happens only for
--- Comment #5 from andreast at gcc dot gnu dot org 2007-12-18 19:07
---
Jack,
you can try, but I think it is a bit wasted time. Well, depends on how long the
process takes to get the patches from apple.
[wolfram:gcc/head/objdir] andreast% file /usr/lib/libffi.dylib
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
Component|bootstrap |other
GCC
--- Comment #7 from spop at gcc dot gnu dot org 2007-12-18 19:40 ---
Subject: Bug 34123
Author: spop
Date: Tue Dec 18 19:40:35 2007
New Revision: 131040
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131040
Log:
2007-12-18 Sebastian Pop [EMAIL PROTECTED]
PR
--- Comment #8 from spop at gcc dot gnu dot org 2007-12-18 19:42 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
In the following code, libstdc++'s debug mode does not catch the use of a
potentially invalidated std::string iterator.
#define _GLIBCXX_DEBUG
#define _GLIBCXX_DEBUG_PEDANTIC
#include string
#include vector
#include iostream
int main()
{
typedef std::string S;
S s (3,
--- Comment #4 from steven at gcc dot gnu dot org 2007-12-18 19:44 ---
Patch was pre-OKed. Andrew, what happened next, did you commit it and is this
bug fixed already?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-12-18 19:52 ---
(In reply to comment #4)
Patch was pre-OKed. Andrew, what happened next, did you commit it and is this
bug fixed already?
Hmm, I had not got already to creating a new patch. This weekend should be a
good
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 19:58 ---
Nothing happened for almost two years.
Perhaps we should close this kind of bug-goes-nowhere bug as WONTFIX?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21953
--- Comment #7 from steven at gcc dot gnu dot org 2007-12-18 19:59 ---
3.5 years with no progress whatsoever.
Should probably closed as WONTFIX?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18346
--- Comment #1 from pcarlini at suse dot de 2007-12-18 20:00 ---
Did you read the documentation?
http://gcc.gnu.org/onlinedocs/libstdc++/ext/debug_mode.html
in a nutshell, our design doesn't provide safe iterators for basic_string.
--
pcarlini at suse dot de changed:
--- Comment #33 from steven at gcc dot gnu dot org 2007-12-18 20:02 ---
Honza, since you re-opened this, perhaps you can give new timings?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from steven at gcc dot gnu dot org 2007-12-18 20:06 ---
As of today this is an ICE at least on Cygwin. cc1 segfaults during inlining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
--- Comment #26 from steven at gcc dot gnu dot org 2007-12-18 20:09 ---
Bring back on the radar for the release manager.
New timings would be much appreciated. Anyone?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:20 ---
Outline/plan for a fix here:
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00354.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21312
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:23 ---
Not sure what to do with this one. Rainer, can you live with WONTFIX? :-)
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-12-18 20:29 ---
See http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg01406.html for recent test
suite results. The first three failures are gone, as observed by Andreas too.
The largefile.c failures still exist. But as Andrew
--- Comment #17 from steven at gcc dot gnu dot org 2007-12-18 20:16 ---
After three years of deafening silence, I'm sure closing this as WONTFIX will
perhaps ignite protests from anyone on the CC: list who still cares about this
one. Should that happen, I encourage the respected victim
With 4.3.0 20071212 on hppa:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -O1 -fPIC
ffcall-trampoline.i
./trampoline.c: In function 'is_trampoline_r':
./trampoline.c:1176: error: unrecognizable insn:
(insn 10 9 11 4 ./trampoline.c:1168 (set (reg:SI 100)
(plus:SI (reg:SI 19 %r19)
--- Comment #1 from tbm at cyrius dot com 2007-12-18 20:15 ---
Created an attachment (id=14791)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14791action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34525
--- Comment #21 from steven at gcc dot gnu dot org 2007-12-18 20:15 ---
After three years of deafening silence, I'm sure closing this as WONTFIX will
perhaps ignite protests from anyone on the CC: list who still cares about this
one. Should that happen, I encourage the respected victim
--- Comment #2 from gcc-bugzilla at contacts dot eelis dot net 2007-12-18
20:16 ---
My apologies.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34524
--- Comment #6 from steven at gcc dot gnu dot org 2007-12-18 20:18 ---
Last seen to work: 3.5 years ago.
Progress on getting this fixed since: 0%
Should anyone feel this bug ought to be fixed, I encourage the respected victim
to work on a fix instead of waiting for it :-)
--
steven
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:35 ---
Control flow graph handling has changed significantly in GCC 4.3. Could
someone try this with a recent snapshot from the trunk? If the bug still
exists, please assign it to me and provide me with some instructions
--- Comment #9 from steven at gcc dot gnu dot org 2007-12-18 20:31 ---
Based on comment #8, the patch of comment #6 should probably be committed.
Jim, do you have plans to take care of this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
--- Comment #3 from steven at gcc dot gnu dot org 2007-12-18 20:33 ---
Martin, is this a bug you can still reproduce with the current SVN trunk? If
so, could you provide a backtrace from gdb?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29472
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-18 20:34 ---
Martin, is this a bug you can still reproduce with the current SVN trunk? If
so, could you provide a backtrace from gdb?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29474
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-12-18 21:19 ---
Subject: Bug 32565
Author: dgregor
Date: Tue Dec 18 21:19:41 2007
New Revision: 131041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131041
Log:
2007-12-18 Douglas Gregor [EMAIL PROTECTED]
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-12-18 21:19 ---
Subject: Bug 33965
Author: dgregor
Date: Tue Dec 18 21:19:41 2007
New Revision: 131041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131041
Log:
2007-12-18 Douglas Gregor [EMAIL PROTECTED]
--- Comment #8 from dgregor at gcc dot gnu dot org 2007-12-18 21:19 ---
Subject: Bug 33943
Author: dgregor
Date: Tue Dec 18 21:19:41 2007
New Revision: 131041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131041
Log:
2007-12-18 Douglas Gregor [EMAIL PROTECTED]
This PR is meant to be a central place to record information about this issue.
The default ABI for 32-bit PowerPC GNU/Linux does not pass vectors in AltiVec
registers and does not save and restore AltiVec registers in functions that use
those registers. With -mabi=altivec, vectors are passed in
--- Comment #4 from dgregor at gcc dot gnu dot org 2007-12-18 22:15 ---
Fixed on the trunk
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dgregor at gcc dot gnu dot org 2007-12-18 22:15 ---
Fixed on the trunk
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-12-18 22:16 ---
Fixed on the trunk
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jason at gcc dot gnu dot org 2007-12-18 22:25 ---
Subject: Bug 34206
Author: jason
Date: Tue Dec 18 22:25:20 2007
New Revision: 131044
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131044
Log:
PR c++/34206
* pt.c (tsubst_aggr_type): Do nothing
--- Comment #11 from tkoenig at gcc dot gnu dot org 2007-12-18 22:27
---
This is fixed on trunk, isn't it?
Closing.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2007-12-18 22:44 ---
fixed
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #5 from ismail at pardus dot org dot tr 2007-12-18 23:11
---
Re-tested with no problems now, but machine was under %300 load when this test
failed. Interestingly rest of the regtests passed fine. Anyway this is invalid.
Thanks for the attention.
--
ismail at pardus dot
--- Comment #14 from steven at gcc dot gnu dot org 2007-12-18 23:17 ---
Dave,
Does the test case pass again if you increase the VOPS threshold once more?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
--- Comment #7 from hp at gcc dot gnu dot org 2007-12-18 23:29 ---
This bug was in NEW, not WAITING. It's meant as a note, not a request for
someone else to fix it. thankyou. Fails the same way with r130591, FWIW.
--
hp at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from hp at gcc dot gnu dot org 2007-12-18 23:20 ---
These tests do not fail and no gcc or g++ test fail with the same error
with r130591, so best to close this one. FWIW, instructions are at
simtest-howto.html (I've given personal instructions at least once).
--
hp
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-18 23:31 ---
xf. http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01789.html
I was wrong to object to this patch -- there really doesn't seem to be any
other way. It's funny, on the one hand we complain about the code quality of
--- Comment #14 from jakub at gcc dot gnu dot org 2007-12-18 23:31 ---
Zero initialization would work, sure. I was just worried if it wouldn't result
in code pessimization. The var in the testcase is only unitialized if
exception
is thrown, and exceptions should be exceptional. But
--- Comment #8 from hp at gcc dot gnu dot org 2007-12-18 23:33 ---
Fails the same way with 130591. No closing, thankyouverymuch.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-12-18 23:40 ---
Subject: Bug 34495
Author: dfranke
Date: Tue Dec 18 23:39:56 2007
New Revision: 131047
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131047
Log:
gcc/fortran:
2007-12-19 Daniel Franke [EMAIL PROTECTED]
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-12-18 23:41
---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/fortra
|
--- Comment #12 from crowl at google dot com 2007-12-18 23:46 ---
I think the last fix is incomplete:
namespace {
struct simple { static const int size = 4; };
template typename T
struct generic { static const int size = 4; };
}
struct instantiate {
simple
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-12-18 23:52
---
(In reply to comment #12)
Note that the simple class is correct, but the template instance is not.
Well it was reverted :). See PR 34238 for the reasons why.
--
pinskia at gcc dot gnu dot org changed:
The following is invalid and rejected using -std=f2003, but I wonder whether
one should not also reject it otherwise? What is the string length?
function a(n,m)
integer :: n,m
character(n) a
character(m) a
end
ifort and g95 reject it always.
* * *
If one wants to add only a check
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-12-19 00:23 ---
I forgot to say compile this code with -maltivec -include altivec.h -O2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34529
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-19 00:25 ---
After reload we have:
(insn 35 10 37 2 t.c:9 (set (reg:SI 9 9)
(reg/f:SI 65 lr [122])) 325 {*movsi_internal1} (nil))
(insn 37 35 38 2 t.c:9 (set (reg:SI 9 9)
(const_int 560560 [0x88db0])) 325
Testcase:
vector float b[560560];
vector float c[560560];
void f(void);
vector float Mult(vector float a)
{
b[560560/16] = a;
asm
(:::memory,0,3,4,5,6,7,8,9,10,11,12,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29);
b[560560/16] = a;
}
CUT
We get:
lis 9,0x8
ori
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/80093a381db184c6/
This interface is needed if one wants pass an array descriptor to C; other
vendors have such a documentation as well. It should come with a note that the
interface may change between versions.
Other compilers
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-12-19 00:35 ---
Note here is a better testcase which clobbers all the usable registers:
static vector float b[560560];
void f(void);
vector float Mult(vector float a)
{
b[560560/16] = a;
asm
--- Comment #11 from dfranke at gcc dot gnu dot org 2007-12-19 00:53
---
Having a look ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-12-19 01:28 ---
4.0.2 works:
ld 9,[EMAIL PROTECTED](2)
li 11,-29264
stvx 2,9,11
In 32bit mode for 4.0.3:
lis 9,[EMAIL PROTECTED]
la 9,[EMAIL PROTECTED](9)
li 11,-29264
stvx
--- Comment #15 from danglin at gcc dot gnu dot org 2007-12-19 01:52
---
This went away in mid July on hppa.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tbm at cyrius dot com 2007-12-19 02:04 ---
Breakpoint 1, fancy_abort (file=0x803da8 gcc/reload1.c, line=1086,
function=0x803be1 reload) at gcc/diagnostic.c:640
640 {
(gdb) where
#0 fancy_abort (file=0x803da8 gcc/reload1.c, line=1086,
function=0x803be1
--- Comment #6 from tbm at cyrius dot com 2007-12-19 02:07 ---
(gdb) run -O -fPIC -quiet ~/vtk-vtkImageMaskBits.ii
Starting program: /home/tbm/tmp/gcc/gcc-4.2-m68k-20071218-r131051/gcc/cc1plus
-O -fPIC -quiet ~/vtk-vt
kImageMaskBits.ii
/home/tbm/vtk-vtkImageMaskBits.ii: In function รข
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-19
02:14 ---
Subject: Re: FAIL: gfortran.dg/nan_4.f90 -O tests for errors
Patch: http://gcc.gnu.org/ml/fortran/2007-12/msg00214.html
Tested second version posted and it fixes the fail on hppa-unknown-linux-gnu.
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-19 02:14 ---
Also fails on powerpc-linux-gnu.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tbm at cyrius dot com 2007-12-19 02:34 ---
Works with 4.3.0 20071219.
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #6 from tbm at cyrius dot com 2007-12-19 02:34 ---
(In reply to comment #4)
Breakpoint 1, fancy_abort (file=0x803da8 gcc/reload1.c, line=1086,
function=0x803be1 reload) at gcc/diagnostic.c:640
This was with 4.2 (from SVN).
--
1 - 100 of 105 matches
Mail list logo
