[Bug rtl-optimization/41891] [4.5 Regression] ICE in move_loop_invariants
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |rtl-optimization Summary|ICE in move_loop_invariants |[4.5 Regression] ICE in ||move_loop_invariants Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41891
[Bug c++/41892] generated code increments past enum boundary
--- 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
[Bug bootstrap/38867] [Regression] gcc 4.4.0 20090114 - libjava/configure sets NONE/share/python, need ${prefix}/share/python
--- 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
[Bug fortran/41850] Wrong-code with optional allocatable arrays
--- 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 fortran/41850 * trans-expr.c (gfc_conv_procedure_call): Deallocate intent-out variables only when present. Remove unneccessary present check. 2009-11-01 Tobias Burnus bur...@net-b.de PR fortran/41850 * gfortran.dg/intent_out_6.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/intent_out_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41850
[Bug c/41895] New: _Complex return type changes line numbers in diagnostics
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 for all(?) targets (I've checked
i686, x86_64, sparc64, ppc64, alpha, and armv5tel Linux).
Changing the return type to '_Complex float', without changing anything else,
including the line numbers for the function body declarations and statements,
causes the diagnostic to refer to a different line:
sed 's/^float/_Complex float/' uninit-13b.c uninit-13.c
gcc -O -Wuninitialized -S uninit-13.c
uninit-13.c: In function 'foo':
uninit-13.c:5:16: warning: 'REALPART_EXPR f' is used uninitialized in this
function
This difference occurs on the i686, x86_64, sparc64, ppc64, and alpha targets,
but not the armv5tel target which continues to refer to line 4.
These inconsistencies are seen with gcc-4.5-20091029, 4.4.2, and 4.3.4.
--
Summary: _Complex return type changes line numbers in diagnostics
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41895
[Bug middle-end/41895] _Complex return type changes line numbers in diagnostics
--- 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 = COMPLEX_EXPR D.1249_2, 0.0;
[t2.c : 6] D.1250_4 = f_3;
return D.1250_4;
float:
foo ()
{
complex float f;
float D.1250;
float D.1249;
bb 2:
[t2.c : 5] D.1249_2 = REALPART_EXPR f_1(D);
[t2.c : 5] f_3 = COMPLEX_EXPR D.1249_2, 0.0;
[t2.c : 6] D.1250_4 = REALPART_EXPR f_3;
return D.1250_4;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |middle-end
Ever Confirmed|0 |1
Keywords||diagnostic
Last reconfirmed|-00-00 00:00:00 |2009-11-01 14:05:49
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41895
[Bug c++/41896] New: [cxx0x-lambda] Segfault because of a nested lambda function
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 report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
according to gdb, the segfault originates at: cp/semantics.c:2814, and it's a
null pointer dereferencing. After a bit of inspection, it was revealed that in
the code:
decl = add_default_capture (lambda_stack,
llambda_stack is NULL.
I tried the code:
float nested_lambda()
{
float val;
[val]()
{
float val2 = val;
[val2]()
{
}
}
}
which seems to be working fine.
--
Summary: [cxx0x-lambda] Segfault because of a nested lambda
function
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam dot rak at streamnovation dot com
GCC build triplet: x86_64-unknown-linux
GCC host triplet: x86_64-unknown-linux
GCC target triplet: x86_64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896
[Bug fortran/41850] Wrong-code with optional allocatable arrays
--- 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 fortran/41850 * trans-expr.c (gfc_conv_procedure_call): Deallocate intent-out variables only when present. 2009-11-01 Tobias Burnus bur...@net-b.de PR fortran/41850 * gfortran.dg/intent_out_6.f90: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/intent_out_6.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/trans-expr.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41850
[Bug fortran/41850] Wrong-code with optional allocatable arrays
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41850
[Bug c++/41896] [cxx0x-lambda] Segfault because of a nested lambda function
-- adam dot rak at streamnovation dot com changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896
[Bug c++/41896] [cxx0x-lambda] Segfault because of a nested lambda function
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41896
[Bug fortran/41872] wrong-code: Issues with allocatable scalars
--- 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 deallocate(b) call checkOptional(.true., .false., 7482, b) at the end of the main program of allocatable_scalar_4.f90 (cf. patch). * Explicit Allocate/Deallocate calls do not fail if the variable is already (de)allocated. To check: - Default init with NULL pointer - Allocatable DT with allocatable components (init when allocating; auto dealloc when going out of scope and for intent(out)) The following program fails: subroutine test() integer, allocatable, save :: a if(.not. allocated(a)) then allocate(a) a = 42 else if (.not. allocated(a)) call abort() if (a /= 42) call abort() end if end subroutine test call test() call test() end -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|wrong-code: No auto-|wrong-code: Issues with |deallocation for INTENT(OUT)|allocatable scalars |allocatable scalars | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41872
[Bug fortran/41137] inefficient zeroing of an array
--- 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 faster. Confirmed, BTW. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-01 16:21:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
[Bug target/41894] wrong code with -fno-split-wide-types
--- 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 extract that appears to highlight problem.
From lreg dump file:
;; Pred edge 3 [50.0%] (fallthru)
(note 16 15 17 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(note 17 16 18 4 NOTE_INSN_DELETED)
(insn 18 17 54 4 pr41894.c:29 (set (subreg:QI (reg/v:HI 43 [ tmp ]) 0)
(plus:QI (reg:QI 42 [ D.1188 ])
(const_int -1 [0x]))) 15 {addqi3} (expr_list:REG_DEAD
(reg:QI 42 [ D.1188 ])
(nil)))
(jump_insn 54 18 55 4 (set (pc)
(label_ref 26)) 101 {jump} (nil))
;; End of basic block 4 - ( 6)
;; lr out 28 [r28] 32 [__SP_L__] 34 [argL] 43
;; live out 28 [r28] 32 [__SP_L__] 34 [argL] 43
from greg dump file:
Spilling for insn 18.
Using reg 18 for reload 0
Spilling for insn 18.
Using reg 18 for reload 0
Reloads for insn # 18
Reload 0: reload_in (QI) = (reg:QI 24 r24 [orig:42 D.1188 ] [42])
reload_out (HI) = (reg/v:HI 28 r28 [orig:43 tmp ] [43])
LD_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (reg:QI 24 r24 [orig:42 D.1188 ] [42])
reload_out_reg: (reg/v:HI 28 r28 [orig:43 tmp ] [43])
reload_reg_rtx: (reg:HI 18 r18)
deleting insn with uid = 2.
;; Register dispositions:
42 in 24 43 in 28 44 in 24
;; Hard regs used: 18 19 24 25 28 29 32
Giving
(insn 57 17 18 4 pr41894.c:29 (set (reg:QI 18 r18)
(reg:QI 24 r24 [orig:42 D.1188 ] [42])) 4 {*movqi} (nil))
(insn 18 57 58 4 pr41894.c:29 (set (reg:QI 18 r18)
(plus:QI (reg:QI 18 r18)
(const_int -1 [0x]))) 15 {addqi3} (nil))
(insn 58 18 54 4 pr41894.c:29 (set (reg/v:HI 28 r28 [orig:43 tmp ] [43])
(reg:HI 18 r18)) 8 {*movhi} (nil))
(jump_insn 54 58 55 4 (set (pc)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
[Bug target/41894] wrong code with -fno-split-wide-types
--- 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
[Bug target/41894] wrong code with -fno-split-wide-types
--- 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
[Bug fortran/41137] inefficient zeroing of an array
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41137
[Bug target/41894] wrong code with -fno-split-wide-types
--- 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: What|Removed |Added Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
[Bug fortran/41872] wrong-code: Issues with allocatable scalars
--- 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 PR fortran/41872 * trans-decl.c (gfc_trans_deferred_vars): Do not nullify autodeallocated allocatable scalars at the end of scope. (gfc_generate_function_code): Fix indention. * trans-expr.c (gfc_conv_procedure_call): For allocatable scalars, fix calling by reference and autodeallocating of intent out variables. 2009-11-01 Tobias Burnus bur...@net-b.de PR fortran/41872 * gfortran.dg/allocatable_scalar_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41872
[Bug fortran/41897] New: Support TR 29113: Further Interoperability of Fortran with C
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 happens in the caller. I think for the TR one needs to make it happen in the callee. Note: The draft N1761 is the result of the subgroup. Not all WG5/J3 members are happy with the proposal. At the February 2009 meeting it will be discussed with all members (cf. ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1794.txt). -- Summary: Support TR 29113: Further Interoperability of Fortran with C Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41897
[Bug fortran/41897] Support TR 29113: Further Interoperability of Fortran with C
--- 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 Summary|Support TR 29113: Further |Support TR 29113: Further |Interoperability of Fortran |Interoperability of Fortran |with C |with C http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41897
[Bug fortran/31298] F2003: use mod, operator(+) = operator(.userOp.) not supported
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug c++/41754] initializer list internal compiler segfault
--- 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|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41754
[Bug fortran/35849] wrong line shown in error message for parameter
--- 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 definition. For e-where and sz-where one has the same problem
if they are PARAMETERS. (Unless, I missed something.)
Complete test - might be useful as it tests all error conditions; could be
checked in independenly of fixing the line problem.
INTEGER, PARAMETER, DIMENSION(10) :: A = [(i, i = 1,10)]
INTEGER, PARAMETER, DIMENSION(10) :: B = ISHFTC(j, A, -20) ! { dg-error
Invalid third argument }
INTEGER, PARAMETER, DIMENSION(10) :: C = ISHFTC(1_1, A, j) ! { dg-error
third argument of ISHFTC exceeds BIT_SIZE of first }
INTEGER, PARAMETER, DIMENSION(10) :: D = ISHFTC(3, A, 5) ! { dg-error
second argument of ISHFTC exceeds third argument }
INTEGER, PARAMETER, DIMENSION(10) :: E = ISHFTC(3_1, A) ! { dg-error
second argument of ISHFTC exceeds BIT_SIZE of first argument }
end
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35849
[Bug middle-end/6392] Problems with __restrict__ type qualifier (array)
--- 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 Severity|enhancement |normal Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6392
[Bug tree-optimization/41898] New: GCC ignores restrict on array
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)
link_error ();
return 0;
}
--
Summary: GCC ignores restrict on array
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jason at gcc dot gnu dot org
BugsThisDependsOn: 6392
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41898
[Bug fortran/41872] wrong-code: Issues with allocatable scalars
--- 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 presumably before gfc_trans_deferred_vars is called. * * * Need to add a test for: integer, allocatable :: a allocate(a) deallocate(a) deallocate(a) ! ERROR end (This works already.) And a test for integer, allocatable :: a allocate(a) allocate(a) ! ERROR end which doesn't work. (If it were, the following would not happen.) There is no default initialization to NULL; thus the following crashes: integer, allocatable :: a if (allocated(a)) call abort() end * * * One needs to also add tests for TYPE (incl. default initializer), for CLASS, and for TYPE/CLASS with allocatable components. (SAVE, optional, intent(out), allocate/deallocate statements, automatic deallocation...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41872
[Bug c++/41754] initializer list internal compiler segfault
--- 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
[Bug tree-optimization/41898] GCC ignores restrict on array
--- 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 indeed doesn't help here. Testcase that can be optimized
only because of restrict:
int * __restrict__ a[1];
int * __restrict__ b[1];
extern void link_error (void);
int main()
{
a[0][0] = 0;
b[0][0] = 1;
if (a[0][0] != 0)
link_error ();
return 0;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-01 20:59:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41898
[Bug tree-optimization/41898] GCC ignores restrict on array
--- 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 org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41898
[Bug bootstrap/41899] New: gcc fails to build on OpenSolaris, as gcc uses non-standard option to 'find'
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 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 07 May 2009 GCC 4.4.2 fails to build, dying with an error: libtool: compile: /export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../../../.././libjava/classpath/native/jni/classpath -I../../../include -I../../../../../../.././libjava/classpath/include -I../../../../../../.././libjava/classpath/native/jni/classpath -I../../../../../../.././libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Wstrict-prototypes -pedantic -fexceptions -fasynchronous-unwind-tables -g -O2 -m64 -MT jnilink.lo -MD -MP -MF .deps/jnilink.Tpo -c ../../../../../../.././libjava/classpath/native/jni/classpath/jnilink.c -fPIC -DPIC -o .libs/jnilink.o /bin/sh ../../../libtool --tag=CC --mode=link /export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Wstrict-prototypes -pedantic -fexceptions -fasynchronous-unwind-tables -g -O2 -m64 -no-undefined -m64 -o libclasspath.la jcl.lo jnilink.lo -lsocket -lnsl libtool: link: /usr/ccs/bin/ar cr .libs/libclasspath.a .libs/jcl.o .libs/jnilink.o libtool: link: /usr/ccs/bin/ranlib .libs/libclasspath.a libtool: link: ( cd .libs rm -f libclasspath.la ln -s ../libclasspath.la libclasspath.la ) gmake[8]: Leaving directory `/export/home/drkirkby/gcc-4.4.2/i386-pc-solaris2.11/amd64/libjava/classpath/native/jni/classpath' Making all in java-math gmake[8]: Entering directory `/export/home/drkirkby/gcc-4.4.2/i386-pc-solaris2.11/amd64/libjava/classpath/native/jni/java-math' if /bin/sh ../../../libtool --tag=CC --mode=compile /export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../../../.././libjava/classpath/native/jni/java-math -I../../../include -I../../../../../../.././libjava/classpath/include -I../../../../../../.././libjava/classpath/native/jni/classpath -I../../../../../../.././libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -I/usr/include -g -O2-m64 -MT gnu_java_math_GMP.lo -MD -MP -MF .deps/gnu_java_math_GMP.Tpo -c -o gnu_java_math_GMP.lo ../../../../../../.././libjava/classpath/native/jni/java-math/gnu_java_math_GMP.c; \ then mv -f .deps/gnu_java_math_GMP.Tpo .deps/gnu_java_math_GMP.Plo; else rm -f .deps/gnu_java_math_GMP.Tpo; exit 1; fi libtool: compile: /export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../../../.././libjava/classpath/native/jni/java-math -I../../../include -I../../../../../../.././libjava/classpath/include -I../../../../../../.././libjava/classpath/native/jni/classpath -I../../../../../../.././libjava/classpath/native/jni/native-lib -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -I/usr/include -g -O2 -m64 -MT gnu_java_math_GMP.lo -MD -MP -MF .deps/gnu_java_math_GMP.Tpo -c ../../../../../../.././libjava/classpath/native/jni/java-math/gnu_java_math_GMP.c -fPIC -DPIC -o .libs/gnu_java_math_GMP.o /bin/sh ../../../libtool --tag=CC --mode=link /export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/drkirkby/gcc-4.4.2/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long
[Bug bootstrap/41899] gcc fails to build on OpenSolaris, as gcc uses non-standard option to 'find'
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41899
[Bug target/41900] New: call *%esp shouldn't be generated because of CPU errata
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 address as code).
See Pentium Pro errata 70, Pentium 2 errata A33, Pentium 3 errata E17.
Gcc generates call *%esp for this example, when compiled with -O2
-fomit-frame-pointer -mpreferred-stack-boundary=2:
int main()
{
volatile unsigned code = 0x00c3;
((void (*)(void))code)();
return 0;
}
The code crashes when executed on P6 processor and executes correctly on other
processors.
GCC shouldn't allow direct %esp register for call instruction. (addressing
using %esp is fine).
---
Note: this bug comes from a piece of code used to call an arbitrary interrupt.
I coded it as this. The call *%esp bug looks weird but is not an artifical
example, it comes from a real code that was written and used.
static void INTR(unsigned int_no)
{
volatile unsigned code = 0xc300cd | (int_no 8);
((void (*)(void))code)();
}
--
Summary: call *%esp shouldn't be generated because of CPU errata
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikulas at artax dot karlin dot mff dot cuni dot cz
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41900
[Bug rtl-optimization/41891] [4.5 Regression] ICE in move_loop_invariants
--- 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 -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -c -o _io.o _io.i frying-pan:~/programs/gambc-v4_5_2-devel /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-checking=release Thread model: posix gcc version 4.5.0 20091014 (experimental) [trunk revision 152748] (GCC) This one fails: 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 -fwrapv -fomit-frame-pointer -fPIC -fno-common -mieee-fp -c -o _io.o _io.i _io.i: In function รข: _io.i:15174:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. frying-pan:~/programs/gambc-v4_5_2-devel /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline --enable-languages=c --enable-checking=release Thread model: posix gcc version 4.5.0 20091015 (experimental) [trunk revision 152797] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41891
[Bug target/41894] wrong code with -fno-split-wide-types
--- 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 as well as R28 frame pointer) It looks like the not ok QI subreg 28/29 of ok HImode r28 is not handled well. The mode restriction is ignored for input reload. (Perhaps because reload decides to use available frame pointer) The output reload needed is 16bit HImode but must be accessible as two QImode subregs. Somehow the mode of output reload gets mangled so we get movw r28,r18 Originally ~2005 the rejection of other modes by avr_hard_regno_mode_ok for r28 was only applied when reload was in progress and frame_pointer_required. So I reapplied this condition and the bug was solved. This function does not need frame pointer so r28 and r29 are indeed freely available. /* Otherwise disallow all regno/mode combinations that span r28:r29. */ if (reload_in_progress frame_pointer_needed regno = (REG_Y + 1) (regno + GET_MODE_SIZE (mode)) = (REG_Y + 1)) return 0; This also produces better code! One concern is that the modes deemed ok or not are now not constant - and perhaps is the reason why condition was removed. In Gcc 4.5 the spill is exactly the same but it uses R16/r17 with the correct output reload subreg - so seems to figure out that r28 is not ok - suggesting problem is fixed. This may take a while to resolve, with some further research and testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41894
[Bug java/41901] New: gcj -C -ftarget 1.1 produces bytecode that doesn't work in JDK 1.1
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 'chgTarg: Conditional' has occurred ... Interpreting method or (2) fails to synchronize correctly and instead throws java.lang.IllegalMonitorStateException in an infinite loop. While this is clearly not ideal behavior for the VM, this VM defines the 1.1 target, so -ftarget 1.1 should produce bytecode that actually works. Sun introduced a similar bug into their javac starting in JDK 1.4, and has failed to fix it, leaving no good way to produce backwards-compatible bytecode. See: http://forums.sun.com/thread.jspa?threadID=196703forumID=37 http://lists.apple.com/archives/Java-dev/2002/Jun/msg00977.html http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4017866 -- Summary: gcj -C -ftarget 1.1 produces bytecode that doesn't work in JDK 1.1 Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bens at alum dot mit dot edu GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41901
[Bug lto/41902] New: Compile error in gcc/lto/lto-elf.c (SHN_XINDEX undeclared)
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. -I. -I../../../sources/gcc-4.5.x/gcc -I../../../sources/gcc-4.5.x/gcc/. -I../../../sources/gcc-4.5.x/gcc/../include -I../../../sources/gcc-4.5.x/gcc/../libcpp/include -I../../../sources/gcc-4.5.x/gcc/../libdecnumber -I../../../sources/gcc-4.5.x/gcc/../libdecnumber/dpd -I../libdecnumber -DCLOOG_PPL_BACKEND -I/cygdrive/c/arm-elf-cy/libelf-0.8.12/include -I/cygdrive/c/arm-elf-cy/libelf-0.8.12/include/libelf ../../../sources/gcc-4.5.x/gcc/c-lang.c -o c-lang.o ../../../sources/gcc-4.5.x/gcc/lto/lto-elf.c: In function 'lto_elf_file_close': ../../../sources/gcc-4.5.x/gcc/lto/lto-elf.c:630: error: 'SHN_XINDEX' undeclared (first use in this function) ../../../sources/gcc-4.5.x/gcc/lto/lto-elf.c:630: error: (Each undeclared identifier is reported only once ../../../sources/gcc-4.5.x/gcc/lto/lto-elf.c:630: error: for each function it appears in.) make[2]: *** [lto/lto-elf.o] Error 1 SHN_XINDEX seems to be internal to libelf This is with svn rev 153796. -- Summary: Compile error in gcc/lto/lto-elf.c (SHN_XINDEX undeclared) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bruck dot michael at googlemail dot com GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: arm-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41902
