--- Comment #7 from dorit at il dot ibm dot com 2006-01-04 07:36 ---
(sorry, didn't notice it was already diagnosed as such)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25590
--- Comment #6 from dorit at il dot ibm dot com 2006-01-04 07:33 ---
Maybe related to:
2005-12-26 Kazu Hirata <[EMAIL PROTECTED]>
PR tree-optimization/25125
* convert.c (convert_to_integer): Don't narrow the type of a
PLUX_EXPR or MINUS_EXPR if !flag_wrapv and
--- Comment #1 from prafullat at kpitcummins dot com 2006-01-04 07:20
---
Hi,
We found a patch for this PR16665.
The Google cache link is as given below (We could not locate any
other link for it),
http://66.249.93.104/search?q=cache:YpH6FllSZGMJ:svn.uludag.org.tr/pardus/pardus-deve
I got a following internal error.
$ gfortran --version
GNU Fortran 95 (GCC) 4.2.0 20051216 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU Gen
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-04 04:24
---
The problem is as follows:
(1) cp_parser_nested_name_specifier_opt defers accessing checking.
(2) In the case that it is parsing tentatively, it creates a
CPP_NESTED_NAME_SPECIFIER token, recording the access che
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-01-04 03:44
---
(In reply to comment #8)
> Disagree with known to work 4.0.2 - original report was from 4.0.2.
I actually disagree with saying the compiler you are using is a 4.0.2 compiler.
It is a 4.0.3 compiler from the date
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-01-04 03:42
---
*** Bug 25659 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-04 03:42 ---
The reduced testcase for this one is:
template class obj_pool {
public:
T *allocate(S *sim, const I& id) {
return Allocator(sim, id);
}
};
namespace simulator {
struct arm_simulator {
static int *mach_
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-01-04 03:25
---
This is not a bug. gfortran behavior is identical to ifort.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24886
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-04
02:41 ---
Subject: Re: ACATS cxg1005 fails at runtime on hppa-linux
> May be this one?
Nope.
There seems to be an optimisation issue. I rebuilt the runtime
at -O0. The test passes when compiled at -O0 and -O1,
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-04 02:26 ---
Reducing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25659
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.0/4.1 regression] ICE in |[4.0/4.1/4.2 regression] ICE
|build_call, at cp/cal
--
debian-gcc at lists dot debian dot org changed:
What|Removed |Added
Severity|normal |major
Keywords||ice-on-
--- Comment #1 from debian-gcc at lists dot debian dot org 2006-01-04
02:21 ---
Created an attachment (id=10580)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10580&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25659
[forwarded from http://bugs.debian.org/336021]
seen with 4.0 20051204 and 4.1 20051124
$ g++ -c armsim.ii
../libosm/object_pool.hpp: In member function 'T* obj_pool::allocate(S*, const I&) [with T = _opt_machine_, I = unsigned int, S
= simulator::arm_simulator, T* (* Allocator)(S*, I) =
simulator
--- Comment #7 from uttamp at us dot ibm dot com 2006-01-04 02:02 ---
Yes, I'll.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-04 01:52 ---
Oh, I forgot to mention that the patch which caused PR 25578 was:
2005-12-23 Paolo Bonzini <[EMAIL PROTECTED]>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-04 01:49 ---
I wonder if this is related at all to PR 25578 which was just fixed today:
2006-01-03 Paolo Bonzini <[EMAIL PROTECTED]>
PR rtl-optimization/25578
* combine.c (combine_simplify_rtx, force_to_mode):
--- Comment #3 from uttamp at us dot ibm dot com 2006-01-04 01:47 ---
peak options are,
"-O3 -mcpu=power4 -ffast-math -ftree-loop-linear -funroll-loops -fpeel-loops
-m32"
base options are,
"-O2 -mcpu=power4 -m32"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25656
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-04 01:46 ---
(In reply to comment #2)
> And SuSE's tester:
> http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html
Oh, that is a x86_64, SuSE's ppc64 tester looks to be down.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from uttamp at us dot ibm dot com 2006-01-04 01:46 ---
peak options are,
"-O3 -mcpu=power4 -ffast-math -ftree-loop-linear -funroll-loops -fpeel-loops
-m32"
base options are,
"-O2 -mcpu=power4 -m32"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-04 01:27 ---
And SuSE's tester:
http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25657
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-04 01:26 ---
And SuSE's tester:
http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25656
This testsuite fails due to a timeout on this 3GHz P4 machine with 1GB PC3200
DDR.
The actual runtime when run manually (it exits successfully)
is reported by time as:
"mmix 1.exe 397.73s user 0.07s system 100% cpu 6:37.71 total"
Admittedly, the mmix simulator could be faster, but I think
the test
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 01:23 ---
Hmm, this seems to work on Diego's tester on powerpc64-linux-gnu:
http://people.redhat.com/dnovillo/spec2000.ppc64/gcc/log/20060103/CFP2000.084.html
What options are you using?
--
http://gcc.gnu.org/bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 01:22 ---
Hmm, this seems to work on Diego's tester:
http://people.redhat.com/dnovillo/spec2000.ppc64/gcc/log/20060103/CFP2000.084.html
What options are you using?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25656
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-04 01:16 ---
Oh, right I should be handling this soon. The rest of objc are because of PR
25464 which is harder to fix as I also have to look into making sure that
methods are encoded correctly still.
--
pinskia at gcc dot g
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-01-04 01:11 ---
This is also related to PR 20308 (I think they are more than related, I think
they are the same bug but reproducing in a different way).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from jsm28 at gcc dot gnu dot org 2006-01-04 01:08 ---
Appeared between 109012 and 109267 on i686-pc-linux-gnu, hppa2.0w-hp-hpux11.11,
hppa64-hp-hpux11.11.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from mmitchel at gcc dot gnu dot org 2006-01-04 01:07
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-01-04 01:07
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #5 from hp at gcc dot gnu dot org 2006-01-04 01:06 ---
Also seen for 109236 (new test) with cross to
mmix-knuth-mmixware, cris-axis-elf, cris-axis-linux-gnu,
i686-pc-linux-gnu (native FC2), sh-elf, mips-elf:
Running
/home/hp/combined/combined/gcc/testsuite/objc.dg/gnu-encodin
Since 23rd Dec. this benchmark getting runtime error with "miscompare output".
I'm doing regression hunt to track the patch which most probably have caused
the failure.
Since similar problem is reported for fma3d benchmark (maybe the same patch has
caused the problem)
Has this seen on other platfo
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-01-04 01:04
---
Subject: Bug 25492
Author: mmitchel
Date: Wed Jan 4 01:04:51 2006
New Revision: 109307
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109307
Log:
PR c++/25492
* name-lookup.c (push_class_l
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-01-04 01:04
---
Subject: Bug 25625
Author: mmitchel
Date: Wed Jan 4 01:04:51 2006
New Revision: 109307
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109307
Log:
PR c++/25492
* name-lookup.c (push_class_l
--- Comment #7 from mmitchel at gcc dot gnu dot org 2006-01-04 01:04
---
Subject: Bug 25625
Author: mmitchel
Date: Wed Jan 4 01:04:03 2006
New Revision: 109306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109306
Log:
PR c++/25492
* name-lookup.c (push_class_l
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-01-04 01:04
---
Subject: Bug 25492
Author: mmitchel
Date: Wed Jan 4 01:04:03 2006
New Revision: 109306
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109306
Log:
PR c++/25492
* name-lookup.c (push_class_l
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-01-04 01:03
---
Subject: Bug 25625
Author: mmitchel
Date: Wed Jan 4 01:03:26 2006
New Revision: 109305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109305
Log:
PR c++/25492
* name-lookup.c (push_class_l
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-01-04 01:03
---
Subject: Bug 25492
Author: mmitchel
Date: Wed Jan 4 01:03:26 2006
New Revision: 109305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109305
Log:
PR c++/25492
* name-lookup.c (push_class_l
Since 23rd Dec. this benchmark getting runtime error with "miscompare output".
I'm doing regression hunt to track the patch which most probably have caused
the failure.
--
Summary: runtime error with 191.fma3d benchmark
Product: gcc
Version: 4.2.0
Sta
--- Comment #4 from hp at gcc dot gnu dot org 2006-01-04 00:50 ---
Where it used to work for 108426 I see this for 109236
on (cross from i686-pc-linux-gnu FC2 unless otherwise noted):
mips-elf
sh-elf
i686-pc-linux-gnu (native, FC2)
cris-axis-linux-gnu
cris-axis-elf
mmix-knuth-mmixware
--- Comment #5 from tromey at gcc dot gnu dot org 2006-01-04 00:45 ---
Fixed in 4.1.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #6 from tromey at gcc dot gnu dot org 2006-01-04 00:28 ---
This is mostly fixed.
We still have some issues around the BOM and byte ordering
for UTF-16, UnicodeBig, and UnicodeLittle, presumably caused
by iconv.
So, I'm leaving this open.
--
tromey at gcc dot gnu dot org c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-04 00:27 ---
Confirmed.
Though having this part of classpath would be even cooler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25655
--- Comment #4 from tromey at gcc dot gnu dot org 2006-01-04 00:25 ---
Subject: Bug 19132
Author: tromey
Date: Wed Jan 4 00:25:28 2006
New Revision: 109304
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109304
Log:
PR libgcj/9715, PR libgcj/19132:
* java/nio/ch
--- Comment #5 from tromey at gcc dot gnu dot org 2006-01-04 00:25 ---
Subject: Bug 9715
Author: tromey
Date: Wed Jan 4 00:25:28 2006
New Revision: 109304
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109304
Log:
PR libgcj/9715, PR libgcj/19132:
* java/nio/cha
--- Comment #11 from mark at codesourcery dot com 2006-01-04 00:02 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied
into two different functions
rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
> what about this patch, then (assuming it passes testing)?
--- Comment #10 from mark at codesourcery dot com 2006-01-04 00:01 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied
into two different functions
rakdver at atrey dot karlin dot mff dot cuni dot cz wrote:
>tree const_expr = expr;
>do
> {
>expr =
--- Comment #3 from rleigh at debian dot org 2006-01-03 23:49 ---
Looking at _M_cfile_created as you suggested, it does look like the
documentation is correct as it stands.
Sorry for the waste of time.
Thanks,
Roger
--
rleigh at debian dot org changed:
What|Removed
We should implement something like Sun's signal chaining library for use with
libgcj. This may be required when working with native libraries installing
their own signal handlers...
http://java.sun.com/j2se/1.4.2/docs/guide/vm/signal-chaining.html
--
Summary: Implement signal chaini
--- Comment #9 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-01-03 23:29 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied into two
different functions
> rakdver at gcc dot gnu dot org wrote:
> > --- Comment #6 from rakdver at gcc dot gnu dot org
--- Comment #8 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-01-03 23:24 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied into two
different functions
> --- Comment #7 from mark at codesourcery dot com 2006-01-03 23:01 ---
> Subject: Re: [4
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-03 23:23 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
In the following C code, the order of loads and stores is messed up, leading to
wrong code:
extern void abort (void) __attribute__((noreturn));
union setconflict
{
short a[20];
int b[10];
};
int
main ()
{
int sum = 0;
{
union setconflict a;
short *c;
c = a.a;
asm ("": "=r
--- Comment #7 from mark at codesourcery dot com 2006-01-03 23:01 ---
Subject: Re: [4.0/4.1/4.2 Regression] ICE with const int copied
into two different functions
rakdver at gcc dot gnu dot org wrote:
> --- Comment #6 from rakdver at gcc dot gnu dot org 2006-01-03 22:40
> --
--- Comment #3 from tromey at gcc dot gnu dot org 2006-01-03 22:58 ---
Subject: Bug 19132
Author: tromey
Date: Tue Jan 3 22:58:31 2006
New Revision: 109294
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109294
Log:
PR libgcj/9715, PR libgcj/19132:
* java/nio/ch
--- Comment #4 from tromey at gcc dot gnu dot org 2006-01-03 22:58 ---
Subject: Bug 9715
Author: tromey
Date: Tue Jan 3 22:58:31 2006
New Revision: 109294
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109294
Log:
PR libgcj/9715, PR libgcj/19132:
* java/nio/cha
--- Comment #2 from arno at heho dot snv dot jussieu dot fr 2006-01-03
22:54 ---
I forgot to mention : correct libjava testsuite results :
=== libjava Summary ===
# of expected passes3964
# of unexpected failures24
# of expected failures 10
--- Comment #2 from pcarlini at suse dot de 2006-01-03 22:42 ---
(In reply to comment #1)
> On further investigation, it looks like when a stdio_filebuf is destroyed,
> this will ultimately invoke __basic_file::close(). This calls fclose().
I think this is not true for the constructor a
--- Comment #6 from rakdver at gcc dot gnu dot org 2006-01-03 22:40 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00136.html
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from steven at gcc dot gnu dot org 2006-01-03 22:39 ---
One part of the problem is fixed, and the test cases now pass.
There is still the RTL alias analysis bug mentioned in the thread on gcc@
starting here: http://gcc.gnu.org/ml/gcc/2006-01/msg8.html. But that is a
--- Comment #19 from steven at gcc dot gnu dot org 2006-01-03 22:37 ---
Subject: Bug 25130
Author: steven
Date: Tue Jan 3 22:37:46 2006
New Revision: 109292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109292
Log:
2006-01-03 Steven Bosscher <[EMAIL PROTECTED]>
* fo
--- Comment #5 from kargl at gcc dot gnu dot org 2006-01-03 22:02 ---
Fixed on trunk. I'll commit to 4.1 in a day or two.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2006-01-03 22:01 ---
Subject: Bug 25101
Author: kargl
Date: Tue Jan 3 22:01:10 2006
New Revision: 109288
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109288
Log:
2006-01-03 Steven G. Kargl <[EMAIL PROTECTED]>
PR fort
--- Comment #4 from laurent at guerby dot net 2006-01-03 21:19 ---
May be this one?
[EMAIL PROTECTED]:~/tmp/pr20754> cat > p2.adb
with Ada.Numerics.Elementary_Functions;
with Ada.Numerics.Complex_Types;
with Ada.Numerics.Complex_Elementary_Functions;
with Ada.Text_IO;
procedure P2 i
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2006-01-03 21:00
---
> Is this still a problem?
Not anymore, the 4.0 vs 4.1 compat testsuite is now clean both in 32-bit and
64-bit mode.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rleigh at debian dot org 2006-01-03 20:52 ---
On further investigation, it looks like when a stdio_filebuf is destroyed, this
will ultimately invoke __basic_file::close(). This calls fclose(). If
an fd is used, fdopen() is called to create a __c_file*.
If this is c
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-03 20:37 ---
This is related to PR 18527 but not fixed with -funsafe-loop-optimizations.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from alex at milivojevic dot org 2006-01-03 20:30 ---
Created an attachment (id=10579)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10579&action=view)
one more example of sigsegv
Trivial example where 64-bit gcc binary segfaults.
The code in question is old-style
--- Comment #3 from danglin at gcc dot gnu dot org 2006-01-03 20:29 ---
That was with 4.0.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754
--- Comment #2 from danglin at gcc dot gnu dot org 2006-01-03 20:27 ---
[EMAIL PROTECTED]:~/gcc_test$ ./p
1.00E+00
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20754
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-03 20:02 ---
Actually this turns out to be the same as PR 18527.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from laurent at guerby dot net 2006-01-03 19:44 ---
The Ada runtime does not use C complex primitives. In this case, the culprit in
all three case is likely to be the following code in ada/a-ngelfu.adb
-- Arctan --
-- Natural cycle
--- Comment #11 from laurent at guerby dot net 2006-01-03 19:36 ---
(In reply to comment #7)
> There's only one fail in 4.0.3:
>
> http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00025.html
>
> RUN cxg1005
>
> ,.,. CXG1005 ACATS 2.5 06-01-01 01:38:37
> CXG1005 Check that the sub
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-03 19:31
---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
>
>
>
> --- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 ---
> For most (if not all) s-osinte
>
>
>
> --- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 ---
> For most (if not all) s-osinte*.ads C type redeclarations, I believe it should
> be sufficient to use a record containing a
> System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an
> alig
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-03 19:29 ---
Closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #1 from palladia at yahoo dot com 2006-01-03 19:25 ---
$which gcc
/home/gfleming/local/bin/gcc
$gcc -v
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.0.2/configure --prefix=/home/gfleming/local
--enable-language=c,c++,java
Thread model: posix
gcc version 4.0.2
$pwd
/h
--- Comment #9 from laurent at guerby dot net 2006-01-03 19:24 ---
For most (if not all) s-osinte*.ads C type redeclarations, I believe it should
be sufficient to use a record containing a
System.Storage_Elements.Storage_Array of the C sizeof(struct), plus may be an
alignement clause (I
Using libstdc++, I've got code like this:
__gnu_cxx::stdio_filebuf fdbuf(fd, std::ios::in);
The doxygen docs for this fd ctor say "The file descriptor will be
automatically closed when the stdio_filebuf is closed/destroyed.", but I appear
to be leaking fds due to making the assumption I was pas
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-01-03 18:49
---
Of course this is not fixed in 4.0.x yet so reopening.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-03 18:45 ---
Steven, I am assigning this from your suse account (one which does exist any
more) to your @gcc.gnu.org account, if you don't have the time to look into
this again, can you assign it to me as I was looking into it an
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-01-03 18:39 ---
You are confused about what load PRE does. It will not lift these load because
it is not partially redundant.
You are looking for some sort of generic code hoister.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-03 18:36 ---
Here is a newer patch which fixes it:
Index: trans-array.c
===
--- trans-array.c (revision 109225)
+++ trans-array.c (working copy)
@@ -1942
--- Comment #9 from dberlin at gcc dot gnu dot org 2006-01-03 18:29 ---
Load PRE on globals is going to take a while, because we do some stupid things
in hashing (like hashing tcc_declaration's by pointer, instead of DECL_UID).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-01-03 17:09 ---
Not PPC specific.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triple
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-03 17:07 ---
Not PPC specific.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triple
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-03 17:06 ---
Not PPC specific.
Also fixed in 4.1.0 and above:
In file t.f90:3
19 real :: a=5
1
Error: Too many digits in statement label at (1)
--
pinskia at gcc dot gnu dot org changed:
What|R
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-03 17:04 ---
Not PPC specific.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triple
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-03 16:59 ---
Not PPC specific.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triple
--- Comment #1 from arno at heho dot snv dot jussieu dot fr 2006-01-03
16:43 ---
Created an attachment (id=10578)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10578&action=view)
Add support for amd64--freebsd
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25652
Hello,
Java is not supported for the amd64--freebsd targets, essentially
because of lacking support in boehm-gc.
I created a simple patch to do so :
- no credits to me: most of this is directly inspired
by the official freebsd-port of boehm-gc
- tested for over 6 months on a non-graphical a
--- Comment #2 from dje at gcc dot gnu dot org 2006-01-03 16:29 ---
Not powerpc-specific.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|po
--- Comment #2 from dje at gcc dot gnu dot org 2006-01-03 16:27 ---
Not powerpc-specific.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|po
--- Comment #2 from dje at gcc dot gnu dot org 2006-01-03 16:25 ---
Not powerpc-specific.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|po
--- Comment #8 from hainque at adacore dot com 2006-01-03 16:25 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
charlet at adacore dot com wrote:
> Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment...
Yes, the latter
charlet at adacore dot com wrote:
> Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment...
Yes, the latter is 8, computed from GCC's BIGGEST_ALIGNMENT.
> Is it really the case that the C headers mandate an alignment of 16 for this
> type which is not guaranteed by malloc ?
IIU
--- Comment #20 from pinskia at gcc dot gnu dot org 2006-01-03 15:54
---
4.2.0 produces good code on x86 also.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #24 from dje at gcc dot gnu dot org 2006-01-03 15:50 ---
Comment #21 mentions three divisions for the optimization to be more
profitable, but that information is lost by the time GCC reaches the expanders.
Minimally, it would be helpful to know that the reciprocal optimizatio
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-03
15:49 ---
Subject: Re: FAIL: a85013b: *** glibc detected *** free(): invalid pointer:
0x00062a00 ***
> Hmm, so that means that 16 is bigger than Standard'Maximum_Alignment...
Unfortunately, yes. The fundamental
1 - 100 of 149 matches
Mail list logo
