--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|middle-end |rtl-optimization
Summary|ICE in move_loop_invariants
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-01 10:26 ---
You should report this to RedHat, RedHat ships modified GCCs. Alternatively
reproduce this with a FSF release.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41892
--- Comment #4 from rwild at gcc dot gnu dot org 2009-11-01 11:39 ---
patch and additional questions at
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00017.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38867
--- Comment #6 from burnus at gcc dot gnu dot org 2009-11-01 12:43 ---
Subject: Bug 41850
Author: burnus
Date: Sun Nov 1 12:43:42 2009
New Revision: 153793
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153793
Log:
2009-11-01 Tobias Burnus bur...@net-b.de
PR
cat uninit-13b.c
float
foo(void)
{
_Complex float f;
__imag__ f = 0;
return f;
}
gcc -O -Wuninitialized -S uninit-13b.c
uninit-13b.c: In function 'foo':
uninit-13b.c:4:20: warning: 'REALPART_EXPR f' is used uninitialized in this
function
This is as expected, and occurs consistently
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-01 14:05 ---
Confirmed. The IL difference doesn't hint at a reason.
_Complex float:
foo ()
{
complex float f;
complex float D.1250;
float D.1249;
bb 2:
[t2.c : 5] D.1249_2 = REALPART_EXPR f_1(D);
[t2.c : 5] f_3 =
Code for triggering the BUG:
float nested_lambda()
{
float val;
[val]()
{
[val]()
{
}
}
}
float nested_lambda() nested_lambda()::lambda()
stdin:7:4: internal compiler error: Szegmens hiba
Please submit a full bug
--- Comment #7 from burnus at gcc dot gnu dot org 2009-11-01 14:35 ---
Subject: Bug 41850
Author: burnus
Date: Sun Nov 1 14:35:40 2009
New Revision: 153794
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153794
Log:
2009-11-01 Tobias Burnus bur...@net-b.de
PR
--- Comment #8 from burnus at gcc dot gnu dot org 2009-11-01 14:36 ---
FIXED on the trunk (4.5) and on the 4.4 branch.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
adam dot rak at streamnovation dot com changed:
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896
--- Comment #3 from burnus at gcc dot gnu dot org 2009-11-01 16:08 ---
First patch: http://gcc.gnu.org/ml/fortran/2009-11/msg1.html
TODO:
* For ALLOCATABLE, OPTIONAL dummies: If the argument is present but not
allocated, PRESENT() returns false. As test case add the lines
--- Comment #5 from tkoenig at gcc dot gnu dot org 2009-11-01 16:21 ---
A workaround (which should really be implemented within the compiler):
subroutine s(a,n)
integer :: n
real :: a(n*n*n*n)
a = 0.0
end subroutine
This is legal Fortran, equivalent to your routine, and should be much
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2009-11-01 17:24
---
The problem is still present on 4.3.5 head
I cannot reproduce on 4.5
It looks like reload issue with SUBREG.
Instruction 18 gets reloaded. The output reload is HImode. I will post dump
files but here is
--- Comment #5 from hutchinsonandy at gcc dot gnu dot org 2009-11-01 17:27
---
Created an attachment (id=18945)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18945action=view)
dump file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
--- Comment #6 from hutchinsonandy at gcc dot gnu dot org 2009-11-01 17:27
---
Created an attachment (id=18946)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18946action=view)
dump file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
--- Comment #7 from eric dot weddington at atmel dot com 2009-11-01 17:44
---
(In reply to comment #4)
The problem is still present on 4.3.5 head
I cannot reproduce on 4.5
Can someone check this to see if bug exists on any 4.4.x?
--
eric dot weddington at atmel dot com changed:
--- Comment #4 from burnus at gcc dot gnu dot org 2009-11-01 17:47 ---
Subject: Bug 41872
Author: burnus
Date: Sun Nov 1 17:46:50 2009
New Revision: 153795
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153795
Log:
2009-11-01 Tobias Burnus bur...@net-b.de
There is a technical report (TR 29113) in preparation to allow Further
Interoperability of Fortran with C.
Last draft is:
ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1761.txt
One thing one presumably needs to change is the way ALLOCATBLE,INTENT(OUT)
variables are auto-deallocated: Currently, it
--- Comment #1 from burnus at gcc dot gnu dot org 2009-11-01 18:03 ---
See also http://gcc.gnu.org/wiki/ArrayDescriptorUpdate
and http://gcc.gnu.org/wiki/LibgfortranAbiCleanup
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-01 19:03 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from burnus at gcc dot gnu dot org 2009-11-01 20:21 ---
(In reply to comment #2)
Do you plan to commit this?
The problem is that the patch is effectively wrong. The s-where is correct -
except that s happens to be a parameter where s-where points to the
parameter
--- Comment #12 from jason at gcc dot gnu dot org 2009-11-01 20:22 ---
Closing the rejects-valid bug, will open a new missed-optimization bug.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Adding a pointless array qualifier to the restrict-1.c test makes it not work
with gcc -O2; we fail to optimize away the call to link_error.
int * __restrict__ a[1];
int * __restrict__ b[1];
extern void link_error (void);
int main()
{
a[0][0] = 1;
b[0][0] = 1;
if (a[0][0] != 1)
--- Comment #5 from burnus at gcc dot gnu dot org 2009-11-01 20:46 ---
SAVE problem: Simply adding (!sym-attr.save (... || ...)) to
gfc_trans_deferred_vars does not work as one then reaches unreachable(); one
should check where SAVE is handles for allocatable arrays, which is
--- Comment #5 from tom dot deseyn at gmail dot com 2009-11-01 20:51
---
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41754
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-01 20:59 ---
Without __restrict__ we don't optimize the call to link_error either. Because
the stores may alias - they are only redundant because of the identical
RHS. See PR23094 for that missed optimization.
But restrict
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-01 21:00 ---
It works with
int * __restrict__ a;
int * __restrict__ b;
extern void link_error (void);
int main()
{
a[0] = 0;
b[0] = 1;
if (a[0] != 0)
link_error ();
return 0;
}
--
rguenth at gcc dot gnu dot
Hi,
Hardware is a Sun Ultra 27 - 3.333 GHz quad core Xeon
Operating system is OpenSolaris (aka Solaris 11) 06/2009
drkir...@hawk:~$ uname -a
SunOS hawk 5.11 snv_111b i86pc i386 i86pc
drkir...@hawk:~$ cat /etc/release
OpenSolaris 2009.06 snv_111b X86
Copyright
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-01 21:10 ---
*** This bug has been marked as a duplicate of 38715 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Hi
Intel P6 family of processors (Pentium Pro, 2, 3) have a bug in call *%esp
instruction. The instruction should put current EIP to stack, decrement ESP by
4 and jump to a value of ESP before the decrement. P6 processors will jump to
the address after the decrement (so the will execute return
--- Comment #3 from lucier at math dot purdue dot edu 2009-11-01 23:55
---
This one works:
frying-pan:~/programs/gambc-v4_5_2-devel /pkgs/gcc-mainline/bin/gcc
-march=core2 -msse4 -save-temps -Wno-unused -O1 -fno-math-errno
-fschedule-insns2 -fno-trapping-math -fno-strict-aliasing
--- Comment #8 from hutchinsonandy at gcc dot gnu dot org 2009-11-02 00:54
---
The problem seems related to use of R28+r29 - which is also frame pointer.
avr_hard_regno_mode_ok allows R28 in HIMODE but not any other mode. (This hack
was made to avoid reload problem where r29 was used
gcj -C -ftarget 1.1 produces output that doesn't work in Sun JDK 1.1.8, as
tested under Wine. The problem is that the bytecode produced for a
synchronized() block is not accepted by the VM. Upon encountering this
bytecode, the VM either (1) prints nonfatal internal JIT (3.00.078(x)) error
gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I.
37 matches
Mail list logo
