--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
07:28 ---
Subject: Bug 22043
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 07:28:26
Modified files:
gcc: ChangeLog expr.c gimplify.c tree-sra.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
08:15 ---
Subject: Bug 23511
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 08:15:19
Modified files:
gcc: ChangeLog tree-ssa-loop-niter.c
Log
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-23
09:50 ---
Changed synopsis and component. Added keyword.
Interestingly, the following is (wrongly) accepted:
- 8< -
interface MyRunnable
{
public void run( );
}
clas
--- Additional Comments From pcarlini at suse dot de 2005-08-23 09:56
---
When push_back notices that s1 is shared and clones it (via reserve), creates
a new string (not shared) of capacity >= original size (according to an
exponential grow policy) but unrelated to the original capacity.
--- Additional Comments From pcarlini at suse dot de 2005-08-23 09:57
---
Thanks Chris. I will work on this issue.
--
What|Removed |Added
AssignedTo|unassigned at gc
--- Additional Comments From oakad at yahoo dot com 2005-08-23 10:27
---
I was dealing with packed structs in this case. Are you sure that
-mstrict-align will not break packing? And I'm talking of both inter- and
intra-struct packing, as in packed array of packed structs.
--
htt
--- Additional Comments From pcarlini at suse dot de 2005-08-23 10:22
---
Of course, first copy-constructing s2, then calling s1.reserve also makes sense.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23494
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
10:40 ---
Subject: Bug 23358
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 10:40:14
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/inclu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:10 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:11 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:16 ---
I don't think this is inefficient at all for the pentium Pro and above because
they don't like the complex
instructions as the older processors do.
And if you want to optimize for size (which gets what yo
--- Additional Comments From charlet at gcc dot gnu dot org 2005-08-23
11:25 ---
You need to use -gnato if you want an exception here.
This test case in any case is handled "as expected" in GCC 4.1 as far as I can
see, unless the mingw build is too old or using non standard sources, but
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:26 ---
This is an ra issue. There is only one load from pc_pipe[1] which x86 does not
like. There is an
actually a different on the tree level but the ra should have handled that but
it does not.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:27 ---
You really should know that we only care about code size at -Os. We care about
performance
regressions though at -O2.
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:34 ---
(In reply to comment #20)
> gcc shouldn't always error out in this situation. For suspend to disk, we
> clobber all registers when restoring the original cpu context after copying
> back
> the original kern
--- Additional Comments From nigel at suspend2 dot net 2005-08-23 11:31
---
gcc shouldn't always error out in this situation. For suspend to disk, we
clobber all registers when restoring the original cpu context after copying back
the original kernel context. We could lie to gcc and say
--
What|Removed |Added
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
--- Additional Comments From ncunningham at cyclades dot com 2005-08-23
11:41 ---
Subject: Re: GCC should error out when clobbering
the stack pointer and frame pointer
The function needs to be inlined - the return value especially is
pivotal in the transition from the booted ke
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:41 ---
This is a dup of bug 23454.
Also please don't copy and paste the preprocessed source into gccbug. Instead
wait to the
confirmation email and attach it to the bug in the web interface or attach it
(and n
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:42 ---
*** Bug 23526 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
nable-languages=c++,objc,java,f95 --prefix=/
home/gates/pinskia/linux --enable-threads=posix --enable-shared
Thread model: posix
gcc version 4.1.0 20050823 (experimental)
So the error message is also a regression but that makes this minor as the
first error message is
correct.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
11:46 ---
Fixed.
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-
The attached testcase compiles and runs correctly with gcc 3.3.4, but gives the
following compilation errors with gcc 3.4.4:
hashtest.cxx: In function `int main()':
hashtest.cxx:11: error: cannot convert `int*' to `std::pair*' in
initialization
hashtest.cxx:12: error: no matching function for call
--- Additional Comments From mattias dot ellert at tsl dot uu dot se
2005-08-23 12:01 ---
Created an attachment (id=9563)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9563&action=view)
The testcase that exemplifies the error
It fails with gcc 3.4.4 but works correctly with gcc 3.
--- Additional Comments From mattias dot ellert at tsl dot uu dot se
2005-08-23 12:02 ---
Created an attachment (id=9564)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9564&action=view)
Patch against the gcc 3.4.4 STL headers
With this patch applied to gcc 3.4.4 it compiles correc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
12:27 ---
Subject: Bug 23467
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 12:26:38
Modified files:
gcc/testsuite : ChangeLog
Added files:
gcc/t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
12:28 ---
Subject: Bug 23467
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 12:27:55
Modified files:
gcc: ChangeLog stor-layout.c
Log message
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
12:36 ---
Subject: Bug 23044
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 12:35:42
Modified files:
gcc/cp : ChangeLog pt.c
gcc/testsuite
--
Bug 18835 depends on bug 23044, which changed state.
Bug 23044 Summary: [4.0/4.1 Regression] ICE on valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23044
What|Old Value |New Value
---
--- Additional Comments From nathan at gcc dot gnu dot org 2005-08-23
12:38 ---
fixed mainline and 4.0
2005-08-23 Nathan Sidwell <[EMAIL PROTECTED]>
PR c++/23044
* pt.c (tsubst_qualified_id): A SCOPE_REF can still remain.
--
What|Removed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
12:39 ---
Subject: Bug 23044
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-23 12:38:53
Modified files:
gcc/cp : Change
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
12:42 ---
This works in both on the mainlline and in 4.0.0. Also the fix is not really a
correct fix as this area was
not what changed between 3.4.0 and 4.0.0.
--
What|Removed |
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
12:45 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From matti dot rintala at iki dot fi 2005-08-23
12:47 ---
(In reply to comment #3)
> You can set env variables per user.
Are you saying that specs files and specs options are not supported in current
gcc and that they should not be used for any purpose?
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
12:49 ---
(In reply to comment #4)
> (In reply to comment #3)
> > You can set env variables per user.
>
> Are you saying that specs files and specs options are not supported in current
> gcc and that they should not
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:15
---
I agree that something much more subtle is going on, maybe even a C++ front-end
bug in 3_4-branch. Notice that hash_map<>::allocator_type is typedef-ed as
_Ht::allocator_type, which, in turn (see the hashtable clas
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
13:15 ---
Confirmed, this is a regression from 3.4.0 where we did not have this access.
It looks like it was caused by:
2005-02-09 Richard Henderson <[EMAIL PROTECTED]>
* builtins.c (DEF_BUILTIN):
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
13:18 ---
I forgot to mention that the preprocessed source from 4.1.0 compiles just fine
with the 3.4.0 compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:26
---
(In reply to comment #5)
I find this very hard to believe: the ext/ headers are basically frozen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:34
---
(In reply to comment #6)
Ok, Andrew is right, just double checked. A big mistery...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:42
---
(In reply to comment #7)
> A big mistery...
Actually, in 3_4-branch memory allocation in class hashtable was rather
different,
forgot about that. The bug is there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
13:42 ---
Oh and the preprocessed created with 3.4.0 gives the same error on the mainline
too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23528
--- Additional Comments From pcarlini at suse dot de 2005-08-23 13:55
---
It looks like the problem has been fixed in revision 1.6 of hashtable.h.
Mattias, can you experiment a bit with just changing in class hashtable:
typedef _Alloc allocator_type;
to
typedef typename _Alloc::t
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
14:15 ---
I see this too.
Compiling with -fno-bounds-check helps, but not enough.
One possibility is simply that our implementation of nextDouble is
inefficient. I doubt this function was coded for maximum performan
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-08-23
14:19 ---
Working on a patch.
--
What|Removed |Added
AssignedTo|pbrook at gcc dot gnu dot |
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
14:19 ---
I tried this with the gcc 4.0 and java-gnome that ship on Fedora Core 4.
It worked for me.
Can you give some more information? Perhaps the stack trace that you see?
Did you compile this or run it interprete
--- Additional Comments From mark at klomp dot org 2005-08-23 14:31 ---
Subject: Re: Sun's JIT faster than gcc for
Random.nextDouble
It looks like the problem is that we don't remove the synchronization
for nextDouble() even though the test case is single-threaded.
qprof: /tmp/
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
14:36 ---
This still seems quite high:
# of unexpected failures91
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20908
--- Additional Comments From kuan_long at hotmail dot com 2005-08-23 14:43
---
-gnato still fail in Mingw 4.1 ,the OS is windows XP
gcc -v
Reading specs from C:/mingw/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --
host=
mi
Fortran code containing preprocessor instructions needed for handling
system-specific behaviour is traditionally written to files with
the extension .F (rather than .f). The GCC driver would preprocess this
file in a first step, writing the intermediate code to a temporary .f file.
The regression
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
14:48 ---
Yes, I think that most invocations of next should be inlined, and wrapped in a
single synchronized block.
Apart from that, I am pretty sure that here
seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) -
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
14:51 ---
> It looks like the problem is that we don't remove the synchronization
> for nextDouble() even though the test case is single-threaded.
If we can remove even only half of the synchronization overhead, by
s
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
14:54 ---
The gfortran bug is PR 18452.
The g77 bug was PR 13008 and was fixed in 3.4.0.
I am going to close this as a dup of the gfortran bug.
*** This bug has been marked as a duplicate of 18452 ***
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
14:54 ---
*** Bug 23532 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
15:06 ---
Fixed by:
+2005-08-23 Mark Mitchell <[EMAIL PROTECTED]>
+
+ * hwint.h (HOST_WIDE_INT_PRINT): Use HOST_LONG_LONG_FORMAT.
+
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
15:12 ---
This is a target bug.
http://groups-beta.google.com/group/comp.lang.ada/browse_thread/thread/ee1a8b8db84c88f/
2195130b88e4dc9d?
lnk=st&q=Ada+exception+block+does+NOT+work%3F&rnum=1#2195130b88e4dc9d
Most li
The compiler generates the following error (includes command building the file)
when building a cross compiler out of GCC HEAD. This also happens on the
20050813 snapshot but does NOT happen on the May 15, 2005 snapshot.
- Pasted console log below -
/
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
15:44 ---
*** This bug has been marked as a duplicate of 21766 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
15:44 ---
*** Bug 23535 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
16:02 ---
Also fails with cvs head.
Offhand I suspect a compiler bug.
--
What|Removed |Added
--- Additional Comments From ajocksch at redhat dot com 2005-08-23 16:05
---
Sorry, I should have clarified earlier that I'm developing with Java-Gnome head.
I am running it interpreted through Eclipse.
Here's the stack trace it generates:
Exception in thread "main" java.lang.Incompatib
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
16:27 ---
tree.c:5027 (build_method_type_directly)7305888: 3.6% 0:
0.0% 596640: 0.9% 0:
0.0% 82318
cp/name-lookup.c:1241 (begin_scope) 8848872: 4.3% 0:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
16:32 ---
I will need someone to test DCE before FRE for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
16:40 ---
I think the FIXME in tree-ssa-operands.c is the answer here:
/* FIXME - if we have better information from the static vars
analysis, we need to make the cache call site specific. This way
we can
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
16:34 ---
Confirmed:
*a = 1;
*b = 2;
t = *a;
operator delete (a);
operator delete (b);
return t;
--
What|Removed |Added
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-23
16:52 ---
Could you show what the code looks like before and after FRE?
I imagine FRE eliminates one a/b, which isn't really making a mess of loads.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
16:53 ---
(In reply to comment #2)
> I imagine FRE eliminates one a/b, which isn't really making a mess of loads.
It is eliminating the loads of a and b too but nothing (maybe it is the job of
the ra), moves the loa
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
17:02 ---
Here is the complete test case:
import java.text.*;
import java.util.*;
public class pr23183 {
public static void main(String[] args) {
SimpleDateFormat sdf = new SimpleDateFormat("''-MM-dd HH:mm:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
17:13 ---
As reported here:
http://gcc.gnu.org/ml/gcc-regression/2005-08/msg00040.html
This is testsuite problem caused by the update of the address of the FSF.
--
What|Removed |Ad
--- Additional Comments From mattias dot ellert at tsl dot uu dot se
2005-08-23 17:14 ---
(In reply to comment #10)
Your proposed alternative patch works for me. Both for the testcase in this bug
report and when I compile the code I was building when I found the bug.
--
http://gcc.g
--- Additional Comments From tobi at gcc dot gnu dot org 2005-08-23 17:24
---
I just received this e-mail:
...
Whilst at the airport, I saw a solution to PR18878, whose existence has
bugged me for ages because it looks as if it should be easy. I though
that I would get it to you, via
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
17:48 ---
Subject: Bug 23517
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 17:48:37
Modified files:
gcc: ChangeLog fold-const.c convert.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
18:01 ---
Subject: Bug 23517
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-23 18:01:27
Modified files:
gcc: Change
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-08-23
18:02 ---
(note: the tree-vect-generic.c part is not needed on 4.0)
Fixed.
--
What|Removed |Added
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-23 18:05 ---
(In reply to comment #2)
> You really should know that we only care about code size at -Os. We care
about performance
> regressions though at -O2.
Code size is important for performance for mode
On Aug 23, 2005, at 2:06 PM, dann at godzilla dot ics dot uci dot edu
wrote:
--- Additional Comments From dann at godzilla dot ics dot uci dot
edu 2005-08-23 18:05 ---
(In reply to comment #2)
You really should know that we only care about code size at -Os. We
care
about perfor
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-23
18:07 ---
Subject: Re: bigger version of mov + cmp produced
On Aug 23, 2005, at 2:06 PM, dann at godzilla dot ics dot uci dot edu
wrote:
>
> --- Additional Comments From dann at godzilla dot ics dot uci do
--- Additional Comments From dann at godzilla dot ics dot uci dot edu
2005-08-23 18:15 ---
(In reply to comment #4)
>
> Then use -Os every where instead. You will see that the overall code
> size for 4.1
> has reduced from 4.0.
That might be true, but -Os is not always an option. If t
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-23
18:26 ---
I have proposed a patch for this problem:
http://gcc.gnu.org/ml/java-patches/2005-q3/msg00266.html
--
What|Removed |Added
-
--- Additional Comments From pcarlini at suse dot de 2005-08-23 18:30
---
Kelley, can you please fix the regression that you introduced? (obviously, you
didn't completely regtest the patch). I suggest first padding the new address
to the length of the old one with spaces then, in case th
--- Additional Comments From charlet at gcc dot gnu dot org 2005-08-23
18:42 ---
You need a recent GCC 4.1 for this to "work" as expected, so
gcc 3.4 is indeed not expected to work in this case.
--
What|Removed |Added
-
--- Additional Comments From pcarlini at suse dot de 2005-08-23 18:23
---
(In reply to comment #11)
Thanks a lot. I think adding a proper rebind is the right way to fix the
problem,
already used in mainline and 4_0-branch, by the way.
--
What|Removed
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-23
18:56 ---
FRE can't really do anything about this.
DOM would do the same thing if it was run before DCE.
I'll make the sinker sink loads.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
--- Additional Comments From erik dot edelmann at iki dot fi 2005-08-23
19:54 ---
A patch for this bug has been posted to the mailing list:
http://gcc.gnu.org/ml/fortran/2005-08/msg00406.html
--
What|Removed |Added
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-23
19:58 ---
Reduced test case. Compile to .class, then compile with -findirect-dispatch.
Interpreting works fine.
public class pr23182 {
static class Wrapper {
Object w;
Object get() {
return w;
}
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-23 20:48
---
So, I fixed another case in which we could die in create_pre_exit having
to do with complex return values. But past that, there are failures that
are completely within optimize_mode_switching, e.g. execute/2005
--- Additional Comments From simon at pushface dot org 2005-08-23 20:55
---
The behaviour with -gnato and without is the same. On the other hand, 'digits
18' fails as shown,'digits
9' gives the exception ...
and 'Machine_Overflows is True.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
sing built-in specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ./configure --prefix=/Users/dir/gfortran
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050823 (experimental)
[dranta:~/tests/gfortran-D] dir%
--
Summary: gfortran hangs on old cray fortran
--- Additional Comments From dir at lanl dot gov 2005-08-23 21:03 ---
Created an attachment (id=9570)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9570&action=view)
old program that hangs gfortran
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-23 21:18
---
Confirmed.
gfortran's error reporting and recovery mechanism appears to lead
to hopeless confusion within the scanner/parser whereby it gets
stuck in an infinite loop.
--
What|Removed
This issue was uncovered in porting our existing software to the GNU tool-
chain. We have a number of structures that contain 3 individual bytes of
data. When the GNU tool-chain compiles the source code, it creates a
load/store byte instruction followed by a load/store half-word instruction wit
--
What|Removed |Added
Component|c++ |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23539
--- Additional Comments From rth at gcc dot gnu dot org 2005-08-23 21:30
---
Actually, I lied about the CFG. It's actually 1->3 with 2-3 still forming
the loop. So LCM did the right thing, technically: for the case in which
the loop trip count is zero, we avoid the efpu insn.
The pr
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-23 21:38
---
Can you compile this code with any modern compiler? I used
fsplit to split the code into a set of files that contains
exactly one subprogram per file. Of the 54 *.f files that I
get from fsplit, only 25 of t
--- Additional Comments From mcvick_e at iname dot com 2005-08-23 21:44
---
I should also mention that the target processor for this is the 603, not 603e
or otherwise. Even compiling with the -mtune=603 and -mcpu=603 gives the same
output. And those old processors do not handle mis-
--- Additional Comments From mcvick_e at iname dot com 2005-08-23 22:24
---
The data access exception is incorrect in this sense. The software developer
had updated the status of this issue and states that this causes a Machine
Check exception to occur on our current hardware.
The ob
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-23
22:30 ---
GCC assumes you have unaligned access.
Use -mstrict-align if you want to assume unaligned access does not work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23539
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-23
23:05 ---
Subject: Bug 23462
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-23 23:05:38
Modified files:
libstdc++-v3 : ChangeLog
libstdc++-v3/tests
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-23
23:35 ---
Re. comment #3, you can find a whole load of options to control various things
about gcc's powerpc backend in the manual. For example in the manual for GCC
4.0.1, you can give this page a look:
http://gcc
1 - 100 of 125 matches
Mail list logo
