--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 06:11 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 04:17 ---
Confirmed, a regression from 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
A gcc build from this morning:
$ /home/anton/toolchain/install/bin/gcc -v
Using built-in specs.
Target: powerpc-linux
Configured with: /home/anton/toolchain/gcc/gcc/configure --build=powerpc-linux
--host=powerpc-linux --target=powerpc-linux --enable-targets=powerpc64-linux
--enable-languages=c,c++
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-02-19 02:57
---
(In reply to comment #15)
> processor-dependent in Fortan means compiler dependent
In the same way implemenation defined code is in C and C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-02-19 02:56
---
>From Fortran 2003
9.1.2:
An unformatted record consists of a sequence of values in a processor-dependent
form and may contain data of any type or may contain no data.
processor-dependent in Fortan means compiler
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-19 02:46
---
Read:
http://gcc.gnu.org/ml/fortran/2004-12/msg00139.html
Basicially unformatted input was never meant to be portable.
The way for them to fix their issue is to have a program that writes out the
unformatted data
--- Comment #12 from hjl at lucon dot org 2006-02-19 02:43 ---
Please provide more details on this issue since this is a gcc only problem.
I need references to Fortran standard when I talk to our SPEC people.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #13 from hjl at lucon dot org 2006-02-19 02:44 ---
Need more info.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-19 02:31
---
This is invalid really as the problem is different size of record header.
There is a bug to fix this (PR 19303) but really this is just unportantable
data even with the little/big endian issue fixed.
Please report
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 02:26 ---
Confirmed, also fails on x86_64.
This is a regression from 4.1.0. It also looks like an aliasing issue too as
DCE is removing the statements.
--
pinskia at gcc dot gnu dot org changed:
What|Remo
--- Comment #10 from hjl at lucon dot org 2006-02-19 02:25 ---
FYI, there are only 2 different input files for this benchmark, little endian
and
big endian. My testcase should be valid for all little endian machines.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
Using a gcc build from today I tried one of the autovectorization test cases
and found it over optimized:
$ ~/toolchain/install/bin/gcc -v
Using built-in specs.
Target: powerpc-linux
Configured with: /home/anton/toolchain/gcc/gcc/configure --build=powerpc-linux
--host=powerpc-linux --target=power
--- Comment #9 from hjl at lucon dot org 2006-02-19 02:23 ---
I didn't check how the data was generated. It is taken from a Linux/i686
machine.
I doubt it is invalid. At least, it should be valid on Linux/i686. Another
Fortran compiler has no problem with the testcase.
Jerry, does my O
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-19 02:21 ---
(In reply to comment #2)
> OK, -fwrapv fixes it. But what if I do this, shouldn't it work as I expect?
> (It doesn't without -fwrapv.) Also, what is the safe way to do what I want?
Use -fwrapv since that defines
--- Comment #2 from tomfelker at gmail dot com 2006-02-19 02:20 ---
OK, -fwrapv fixes it. But what if I do this, shouldn't it work as I expect?
(It doesn't without -fwrapv.) Also, what is the safe way to do what I want?
int min = INT_MAX, i;
for(i = 1; i > 0; ++i) {
int candi
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 02:08 ---
This is not a bug in GCC. This is undefined code because of signed overflow.
i * i will always be greater than zero if i is also greater than zero with
signed types unless you use -fwrapv which causes overflow to b
When I compile the following code with -O1 -ftree-vrp or -O2, it prints
-2147483647, instead of 1 as expected. (The intent of the code was to search
for integers which, when squared and truncated, give small positive values.)
#include
#include
#include
int main() {
int min = INT_MAX, i
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-02-19 01:59
---
#6 works on i686 as well. If SPEC 2006 is indeed using non-portable data then
we need to notify. HJ can you look into this for us?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-19 01:41 ---
(In reply to comment #5)
> This points to a compatibility issue, but the fact that it did not fail on the
> first read and did on the second is suspicious.
Not really as there was enough data for the first one but n
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-19 01:40 ---
This program works on powerpc-darwin (and most likely other targets too):
program pr
INTEGER, PARAMETER :: MG=16
REAL,SAVE :: abscoefL1(5,13,MG),abscoefH1(5,13:59,MG), &
SELFREF1(10
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-02-19 01:40
---
I get:
./a.out
At line 15 of file foo.f90
Fortran runtime error: Corrupt unformatted sequential file
This points to a compatibility issue, but the fact that it did not fail on the
first read and did on the secon
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-19 01:30 ---
http://gcc.gnu.org/onlinedocs/gcc-3.0.1/g77_20.html#SEC662
Says they are not portable.
Why are they trying to use unformatted input?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-19 01:20 ---
I am tempting at closing this as invalid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-19 01:19 ---
unformated input is not portable at all and should be baned from SPEC unless
the test is also writting out the unformated data.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #2 from lucier at math dot purdue dot edu 2006-02-19 01:16
---
Subject: Re: Timouts in libgomp tests with --with-long-double-128
On Feb 16, 2006, at 2:41 PM, pinskia at gcc dot gnu dot org wrote:
> First --with-long-double-128 does nothing on Darwin.
Does it do nothing
--- Comment #1 from hjl at lucon dot org 2006-02-19 01:15 ---
Created an attachment (id=10876)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10876&action=view)
A testcase
I got
[EMAIL PROTECTED] unformated]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/gfortran
-B/export/bui
One of the SPEC CPU 2006 benchmark uses unformatted input and it failed at
the rune time.
--
Summary: Unformated input doesn't work
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
--- Comment #30 from neil at daikokuya dot co dot uk 2006-02-19 00:52
---
Subject: Re: no compile time array index checking
rguenth at gcc dot gnu dot org wrote:-
> Also make sure not to trip on
>
> typedef struct {
> int len;
> char str[4];
> } String;
>
> char foo(String *s)
rguenth at gcc dot gnu dot org wrote:-
> Also make sure not to trip on
>
> typedef struct {
> int len;
> char str[4];
> } String;
>
> char foo(String *s)
> {
> return s->str[42];
> }
That definitely deserves a warning.
Neil.
--- Comment #9 from laurent at guerby dot net 2006-02-19 00:23 ---
May be Richard Kenner could help here?
--
laurent at guerby dot net changed:
What|Removed |Added
--- Comment #8 from law at redhat dot com 2006-02-19 00:16 ---
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-0
Currently gcc/doc/contrib.texi has four lists:
- "main" gcc contributors.
- gnats contributors
- libgcj/classpath contributors
- testers
They should be merged.
--
Summary: contrib.texi contributors lists need merging
Product: gcc
Version: 4.1.0
Stat
--- Comment #8 from sgk at troutmask dot apl dot washington dot edu
2006-02-18 23:54 ---
Subject: Re: [4.1/4.2 regression] __convert_i4_i8 written to a module.
On Sat, Feb 18, 2006 at 07:52:27PM -, eedelman at gcc dot gnu dot org
wrote:
>
>
> Index: gcc/fortran/intrinsic.c
> ===
--- Comment #9 from dje at gcc dot gnu dot org 2006-02-18 23:19 ---
Subject: Bug 26350
Author: dje
Date: Sat Feb 18 23:19:02 2006
New Revision: 111255
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111255
Log:
PR target/26350
* config/rs6000/rs6000.md (extenddftf
--- Comment #9 from dje at gcc dot gnu dot org 2006-02-18 23:16 ---
libstdc++ configuration may have detected that the particular feature causing
problems was not present or the header may not have defined the function at
all, causing libstdc++ to provide its own implementation.
The usu
--- Comment #8 from multix at gmail dot com 2006-02-18 23:04 ---
this happens on 3.3.6 too, but I read
http://gcc.gnu.org/ml/gcc/2003-10/msg00110.html
who was able to build 3.3.1 on an even older system. Differences are that he
disabled multilib and shared libraries. I don't see how th
--- Comment #3 from vz-gcc at zeitlins dot org 2006-02-18 22:47 ---
First, thanks a lot Andrew for your lightning fast reply, this is really
amazing -- and incredibly helpful!
Second, really sorry, rereading the explicit specialization section once again
I see that I was indeed wrong an
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-18 22:28 ---
Also see PR 11930 for more help with the issue adding template<> does not emit
the variable.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26355
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-18 22:26 ---
This is invalid code. This is a dup of bug 22095.
The diagnostic issue is filed under PR 20118.
*** This bug has been marked as a duplicate of 22095 ***
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-18 22:26 ---
*** Bug 26355 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from rsandifo at gcc dot gnu dot org 2006-02-18 22:25
---
With the patch that I just committed, you should be able to
get the desired behaviour using -fsection-anchors.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rsandifo at gcc dot gnu dot org 2006-02-18 22:22
---
The patch I committed should provide the general infrastructure,
but an ARM patch will be needed to make use of it. ARM code
would also benefit if we tried to reuse addresses that the
function had to calculate any
I'm not 100% sure if this is a compiler bug or a bug in my code but I think
that what I'm trying to do should be valid according to 14.7.5/4 of the C++
Standard. Please consider the following example:
% cat stsp.cpp
enum V { V1, V2, V3 };
template struct Data { static int Value; };
int Data::Va
--- Comment #8 from rsandifo at gcc dot gnu dot org 2006-02-18 22:07
---
Subject: Bug 9703
Author: rsandifo
Date: Sat Feb 18 22:06:53 2006
New Revision: 111254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111254
Log:
* cselib.c (cselib_init): Change RTX_SIZE to RTX_CO
--- Comment #5 from rsandifo at gcc dot gnu dot org 2006-02-18 22:07
---
Subject: Bug 17106
Author: rsandifo
Date: Sat Feb 18 22:06:53 2006
New Revision: 111254
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111254
Log:
* cselib.c (cselib_init): Change RTX_SIZE to RTX_C
--- Comment #7 from law at redhat dot com 2006-02-18 21:49 ---
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-0
--- Comment #6 from law at redhat dot com 2006-02-18 21:36 ---
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #5 from pinskia at gcc dot gnu dot org 2006-0
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-18 21:09 ---
Subject: Bug 25680
Author: pinskia
Date: Sat Feb 18 21:09:35 2006
New Revision: 111251
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111251
Log:
2006-02-18 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-18 21:09 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from dje at gcc dot gnu dot org 2006-02-18 20:43 ---
Created an attachment (id=10875)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10875&action=view)
patch to place constant 0.0 in MEM and validize to create GOT reference
--
dje at gcc dot gnu dot org changed:
--- Comment #4 from julius at zgod dot cjb dot net 2006-02-18 20:37 ---
On another system with Debian Sarge, I can compile it without problems. It is
then compiled for i686 though instead of i586. Could it be that only compiling
i586 is a problem? Should I try compiling it for i486 or i3
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-18 19:58 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from eedelman at gcc dot gnu dot org 2006-02-18 19:52
---
Here's a small one-liner patch that I think fixes the bug. I'll post it to the
mailing list later tonight if/when it passes regression testing.
Index: gcc/fortran/intrinsic.c
=
--- Comment #7 from jakub at gcc dot gnu dot org 2006-02-18 19:04 ---
Subject: Bug 26334
Author: jakub
Date: Sat Feb 18 19:04:08 2006
New Revision: 111248
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111248
Log:
PR middle-end/26334
* gcc.dg/20060218-
* stmt.c (decl_overlaps_hard_reg_set_p): Use DECL_HARD_REGISTER
instead of DECL_REGISTER.
* gcc.c-torture/compile/20060217-1.c: New test.
* gcc.dg/20060218-1.c: New test.
Added:
trunk/gcc/testsuite/gcc.c-torture/compile/20060217-1.c
trunk/gcc/testsuite/gcc.dg/20060218-1.c
Modified:
--- Comment #4 from pault at gcc dot gnu dot org 2006-02-18 17:52 ---
A patch is on its way for the immediate problem; however, the more complicated
cases of loop reversal and of dependecy involving expressions will have to
wait.
Paul
--
pault at gcc dot gnu dot org changed:
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-02-18 17:32 ---
Acutally f3 is not fixed but I don't understand how not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18908
--- Comment #7 from dje at gcc dot gnu dot org 2006-02-18 17:24 ---
Reload is creating the symbol_ref from the extenddftf2 splitter, which is
trying to load 0.0. I think this is a case where we need to expand
legitimize_reload_address(). Darwin uses that to fix up these insns, but it
c
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-18 17:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-18 17:22 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from hjl at lucon dot org 2006-02-18 17:14 ---
I have seen 9% myself. We are trying to isolate the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26353
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-18 17:13 ---
Confirmed fixed. Thanks Roger.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02 ---
Saw it too.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #5 from dje at gcc dot gnu dot org 2006-02-18 16:47 ---
This appears to be related to -fpic. The SYMBOL_REF is considered small data
and rs6000_legitimate_small_data_p() includes !flag_pic. What is generating
this when -fpic?
--
dje at gcc dot gnu dot org changed:
--- Comment #4 from danglin at gcc dot gnu dot org 2006-02-18 16:41 ---
Also seen on hppa-unknown-linux-gnu:
/home/dave/gnu/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.2/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-
4.2.0/hppa-linux/
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-18 16:38 ---
I would not trust Diego's numbers with my life.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26353
--- Comment #2 from hjl at lucon dot org 2006-02-18 16:37 ---
From
http://people.redhat.com/dnovillo/spec2000.em64t/gcc/log/20060118/CINT2000.759.asc
175.vpr 1400 315 444* 1400 317 442*
From
http://people.redhat.com/dnovillo/spec2000.em64t/baseli
--- Comment #17 from danglin at gcc dot gnu dot org 2006-02-18 16:27
---
Fixed by patch.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Statu
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-18 16:22 ---
I cannot reproduce this at all in 4.0.2, 4.0.0, or 4.0.3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
--- Comment #16 from danglin at gcc dot gnu dot org 2006-02-18 16:21
---
Subject: Bug 13408
Author: danglin
Date: Sat Feb 18 16:21:06 2006
New Revision: 111243
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111243
Log:
PR ada/13408
* pa.h (WIDEST_HARDWARE_FP_SIZ
--- Comment #15 from danglin at gcc dot gnu dot org 2006-02-18 16:17
---
Subject: Bug 13408
Author: danglin
Date: Sat Feb 18 16:17:46 2006
New Revision: 111242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111242
Log:
PR ada/13408
* pa.h (WIDEST_HARDWARE_FP_SIZ
--- Comment #2 from pault at gcc dot gnu dot org 2006-02-18 16:16 ---
A patch is on its way - it's regtesting right now.
This fixes the problem with where_19.f90 as well.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-18 16:16 ---
What is the issue here except for the fact vrp regressed? There is not enough
information even start to look into this bug until there is a testcase which
people who don't have access to SPEC (me) to start looking i
--- Comment #14 from danglin at gcc dot gnu dot org 2006-02-18 16:15
---
Subject: Bug 13408
Author: danglin
Date: Sat Feb 18 16:15:07 2006
New Revision: 111241
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111241
Log:
PR ada/13408
* pa.h (WIDEST_HARDWARE_FP_SIZ
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26291
--- Comment #13 from danglin at gcc dot gnu dot org 2006-02-18 16:12
---
Subject: Bug 13408
Author: danglin
Date: Sat Feb 18 16:12:20 2006
New Revision: 111240
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111240
Log:
PR ada/13408
* pa.h (WIDEST_HARDWARE_FP_SIZ
I saw 9% regression in SPEC CPU 2K 175.vpr -O2 number on Nocona between gcc
3.4.4 and gcc 4.2. Gcc 4.1 and 4.0 have similar regression.
--
Summary: [4.2/4.1/4.0]: 9% regresssion in SPEC CPU 2K 175.vpr on
Nocona
Product: gcc
Version: 4.2.0
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-18 16:07 ---
g++: Internal error: Killed (program cc1plus)
means memory was over used.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-18
16:00 ---
Subject: Re: FAIL: gfortran.dg/secnds.f -O0 execution test
> This test can sometimes fail if you have a lot of background tasks running.
I believe that the only taks running were those associated with
--- Comment #4 from sje at gcc dot gnu dot org 2006-02-18 16:00 ---
Subject: Bug 26189
Author: sje
Date: Sat Feb 18 15:59:57 2006
New Revision: 111238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111238
Log:
PR target/26189
* inclhack.def (hpux_spu_info): New.
--- Comment #3 from sje at gcc dot gnu dot org 2006-02-18 15:58 ---
Subject: Bug 26189
Author: sje
Date: Sat Feb 18 15:58:06 2006
New Revision: 111237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111237
Log:
PR target/26189
* inclhack.def (hpux_spu_info): New.
--- Comment #2 from igodard at pacbell dot net 2006-02-18 15:48 ---
Created an attachment (id=10874)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10874&action=view)
source code (compressed)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
--- Comment #1 from igodard at pacbell dot net 2006-02-18 15:48 ---
Created an attachment (id=10873)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10873&action=view)
compiler output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26352
--
Summary: ICE
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: igodard at pacbell dot net
http://gc
--- Comment #29 from jakub at gcc dot gnu dot org 2006-02-18 15:24 ---
Yes, fairly easily.
Just add another pass, probably into tree-object-size.c, where you:
init_object_sizes ();
and for each ARRAY_REF compute objsz = compute_builtin_object_size
(TREE_OPERAND (array_ref, 0), 0) and if
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-18 15:19 ---
The difference between 4.1 and 4.2 come in the schedule1 pass.
4.1 does something while it looks like 4.2 does not.
-fno-schedule-insns on 4.1 "fixes" the ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2635
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-18 15:08 ---
Error message is
ieee.min2.i:25: error: unrecognizable insn:
(insn 64 63 30 1 (set (reg:DF 8 8)
(mem/u/c/i:DF (symbol_ref/u:SI ("*.LC3") [flags 0x2]) [12 S8 A64])) -1
(nil)
(nil))
ieee.min2.i:25: interna
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-18 15:03 ---
This works in 4.2.0 20060218.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-18 14:56 ---
Would have been nice if you put the error message in the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26350
--- Comment #28 from giovannibajo at libero dot it 2006-02-18 14:48 ---
Jakub, you have provided some infrastructure to compute object size and provide
warnings for unsafe use of builtins. Do you believe that infrastructure could
be reused/enhanced for this bug?
--
giovannibajo at li
--- Comment #3 from law at redhat dot com 2006-02-18 14:47 ---
Subject: Re: ICE compiling a-textio.adb at -O1 -ftree-vrp
On Sat, 2006-02-18 at 11:15 +, laurent at guerby dot net wrote:
>
> --- Comment #2 from laurent at guerby dot net 2006-02-18 11:15 ---
> Jeff mentionne
--- Comment #8 from steven at gcc dot gnu dot org 2006-02-18 14:39 ---
Loop body with GCC 4.0:
:;
j = i + 1;
if (cnt > j) goto ; else goto ;
:;
ivtmp.22 = (int *) ivtmp.31;
ivtmp.19 = 0;
:;
D.2609 = *((int *) ivtmp.31 + 4294967292B);
D.2657 = (int *) ivtmp.22;
D.2614 = *
--- Comment #7 from steven at gcc dot gnu dot org 2006-02-18 14:39 ---
Loop body with GCC 4.1:
:;
j = i + 1;
if (cnt > j) goto ; else goto ;
:;
ivtmp.49 = (int *) ivtmp.54;
j.56 = j;
:;
D.2857 = (int *) j;
D.2751 = MEM[base: lst, index: D.2857, step: 4B, offset: 4294967292B
--- Comment #6 from steven at gcc dot gnu dot org 2006-02-18 14:36 ---
Timings with the same compilers on the same machine, but with -m32
-march=pentium4 (but still with -O2):
GCC 4.0 GCC 4.1
0m4.148s0m8.817s
0m4.140s0m8.785s
0m4.164s0m8.761s
So:
1) We p
--- Comment #27 from dcb314 at hotmail dot com 2006-02-18 14:33 ---
(In reply to comment #21)
> hmm, thanks. it should have looked like this:
I tried your second patch, and the compile of the compiler got as far
as the following
/home/dcb/gnu/42-20060211/working/./prev-gcc/xgcc
-B/home
--- Comment #5 from steven at gcc dot gnu dot org 2006-02-18 14:32 ---
For the record, AMD64 (usr-)timings:
GCC 4.0 GCC 4.1
0m5.412s0m4.400s
0m5.388s0m4.404s
0m5.408s0m4.404s
So for AMD64 we in fact booked significant progress in GCC 4.1 wrt. GCC 4.0.
--- Comment #26 from rguenth at gcc dot gnu dot org 2006-02-18 13:44
---
I agree that the false positives would be acceptable. One could even warn for
[0] and [1] arrays if std=c99 (I believe flexible array members were not in
c89, but i didn't check).
For a way to check if an array a
Invoking java.util.ResourceBundle.getBundle(String) leaks some native memory.
A small sample program is attached. If you run it, you will see that the
process' virual memory size keeps growing while Java heap consumption stays at
a same level after some iteration.
The problem is in gnu.gcj.runti
--- Comment #25 from falk at debian dot org 2006-02-18 13:25 ---
(In reply to comment #24)
> We need to allow offsetting beyond the declared array size if this array is
> the
> last member of a structure. This is refered to as "malloc trick" to allocate
> variable sized structures with
--- Comment #24 from rguenth at gcc dot gnu dot org 2006-02-18 13:15
---
(In reply to comment #22)
We need to allow offsetting beyond the declared array size if this array is the
last member of a structure. This is refered to as "malloc trick" to allocate
variable sized structures wit
1 - 100 of 121 matches
Mail list logo
