[Bug target/36627] New: X86: wrong mode in subqi_2
The pattern subqi_2 and subqi_3 contain a reference to a construct (minus:HI (match_operand:QI) (match_operand:QI)). It is not obvious because the match_operand are written as match_dup. Such a RTL will never be generated. -- Summary: X86: wrong mode in subqi_2 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Erwin dot Unruh at fujitsu-siemens dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36627
[Bug target/36568] infinite _Unwind_Backtrace / thread stack unwinding.
--- Comment #6 from pluto at agmk dot net 2008-06-25 07:52 --- forwarded to libc bugzilla: http://sources.redhat.com/bugzilla/show_bug.cgi?id=6693 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36568
[Bug c++/36628] New: incorrect declspec() handling of conditional operator
I compiled the following code with gcc 4.3.0 mingw (more details at the end of
the report) with:
g++ -std=c++0x test.cpp
#include iostream
#include typeinfo
int rvalue();
int lvalueref();
int rvalueref();
decltype(true ? rvalue() : rvalue()) f()
{}
decltype(true ? lvalueref() : lvalueref()) g()
{}
decltype(true ? rvalueref() : rvalueref()) h()
{}
int main()
{
std::cout typeid(f).name() \n;
std::cout typeid(g).name() \n;
std::cout typeid(h).name() \n;
}
-
The output is:
FivE
FRivE
FOivE
this suggests that declspec() was interpreted respectively as int, int and
int. However a careful reading of clause 5, paragraph 5 and 6, makes it clear
that the result should have been int in all three cases, so correct output
should have been:
FivE
FivE
FivE
The fact is that, when evaluating the type of the arguments of the conditional
operator, int and int should be adjusted to int prior to any further
analysis. Once both the second and third parameters are adjusted to int, the
conditional operator can't help returning an int (5.16/6). To be precise, the
results are an lvalue of type int and rvalue of type int, respectively, but
that is very different from saying that they are int and int and declspec
should be aware of that.
Additional compiler info:
$ g++ -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3.0/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp
--with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug
--enable-concept-checks --enable-version-specific-runtime-libs --build=mingw32
--with-bugurl=http://www.mingw.org/bugs.shtml --prefix=/mingw
--with-gmp=/mingw/src/gcc/gmp-mpfr-root
--with-mpfr=/mingw/src/gcc/gmp-mpfr-root
--with-libiconv-prefix=/mingw/src/gcc/libiconv-root
Thread model: win32
gcc version 4.3.0 20080305 (alpha-testing) mingw-20080502 (GCC)
--
Summary: incorrect declspec() handling of conditional operator
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: abarbati at iaanus dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36628
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-06-25 08:41 --- Subject: Bug 35518 Author: rguenth Date: Wed Jun 25 08:41:14 2008 New Revision: 137100 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137100 Log: 2008-06-25 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/35518 * fold-const.c (fold_ternary): Strip trivial BIT_FIELD_REFs. * tree-sra.c (instantiate_element): Use fold_build3 to build BIT_FIELD_REFs. (try_instantiate_multiple_fields): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug c++/36626] traditional cast not recognized
--- Comment #1 from schwab at suse dot de 2008-06-25 08:53 --- In a cast in functional notation only a simple-type-specifier is allowed. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36626
[Bug c++/36628] [c++0x] incorrect decltype() handling of conditional operator
--- Comment #1 from paolo dot carlini at oracle dot com 2008-06-25 09:15 --- You mean decltype, right? And I would guess you stumbled on the issue while implementing common_type... Let's CC Doug, the main author of the code. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||doug dot gregor at gmail dot ||com Summary|incorrect declspec()|[c++0x] incorrect decltype() |handling of conditional |handling of conditional |operator|operator http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36628
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #21 from rguenth at gcc dot gnu dot org 2008-06-25 10:05 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug target/36627] X86: wrong mode in subqi_2
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-25 10:10 --- Confirmed. Looks like a cutpaste error. Uros? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||uros at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-25 10:10:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36627
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #13 from jakub at gcc dot gnu dot org 2008-06-25 10:20 ---
And the miscompiled tlsc.f inline (compile with just -O2):
SUBROUTINE TLSC (A,B,AUX,IPIV,EPS,X)
COMMON /TLSDIM/ M1,M,N,L,IER
COMMON /SLATE/ BETA,H,I,IB,IB1,ID,ID1,IEND,II,IST,J,JA,JB,JK
+ ,JST,K,KPIV,KR,KST,KT,K1,LV,MR,M11,NK,NR,PIV,PIVT
+ ,SIG,DUM(11)
DIMENSION A(*), AUX(*), B(*), IPIV(*), X(*)
IF (N.GT.M.OR.M1.GT.N) GO TO 90
K1 = MAX (N,L)
IER = 1
DO 5 K=1,N
5 IPIV(K) = K
IST = - N
JB = 1 - L
M11 = M1 + 1
MR = M1
DO 50K=1,N
IF (K.GT.M1) MR = M
IST = IST + N + 1
JB = JB + L
LV = MR - K + 1
PIV = 0.
ID = IST - N
DO 20J=K,N
IF (K.EQ.1 .OR. K.EQ.M11)GO TO 10
PIVT = AUX(J) - A(ID)*A(ID)
GO TO 15
10 I = ID + N
IF (LV .EQ. 1) GO TO 12
CALL TLSMSQ (A(I),N,LV,PIVT)
GO TO 15
12 PIVT= A(I)*A(I)
15 AUX(J) = PIVT
ID = ID + 1
IF (PIVT*EPS.LE.PIV) GO TO 20
PIV = PIVT
KPIV = J
20 CONTINUE
I = KPIV - K
IF (I.LE.0) GO TO 25
H = AUX(K)
AUX(K) = AUX(KPIV)
AUX(KPIV) = H
ID = IST + I
NR = M - K + 1
CALL TLSWOP (A(IST),A(ID),N,NR)
25 CALL TLUK (A(IST),N,LV,SIG,BETA)
IF (LV.EQ.0) GO TO 90
J = K1 + K
AUX(J)=-SIG
IF (K.GE.N) GO TO 30
NK = N - K
IF (LV.EQ.1) GO TO 27
CALL TLSTEP (A(IST),A(IST+1),N,N,LV,NK,BETA)
GO TO30
27 DO 28J=1,NK
JST = IST + J
28 A(JST) = A(JST)*(1.-BETA*A(IST)**2)
30 IB = (K-1) * L + 1
IF (LV.EQ.1) GO TO 32
CALL TLSTEP (A(IST),B(IB),N,L,LV,L,BETA)
GO TO 34
32 DO 33J=1,L
JST = IB + J - 1
33 B(JST) = B(JST)*(1.-BETA*A(IST)**2)
34 IPIV(KPIV) = IPIV(K)
IPIV(K) = KPIV
IF (K.GT.M1) GO TO 50
DO 45I=M11,M
ID1 = IST + (I-K)*N
IF (A(ID1).EQ.0) GO TO 45
H = - A(ID1)/SIG
A(ID1) = H
ID1 = ID1 + 1
ID = IST + 1
DO 35J=1,NK
A(ID1) = A(ID1) - H*A(ID)
ID1 = ID1 + 1
35 ID = ID + 1
IB1 = 1 + (I-1)*L
IB = JB
DO 40J=1,L
B(IB1) = B(IB1) - H*B(IB)
IB1 = IB1 + 1
40 IB = IB + 1
45 CONTINUE
50 CONTINUE
IER = N * IER
KT = N
JK = (N-1) * L
K = K1 + N
PIV = 1./AUX(K)
DO 55K=1,L
JK = JK + 1
55 X(JK) = PIV * B(JK)
KR = N - 1
IF (KR.LE.0) GO TO 70
JST = KR * (N+1) + 2
DO 65J=1,KR
JST = JST - N - 1
IEND= (KR-J+1) * N
K = K1 + KR - J + 1
PIV = 1./AUX(K)
KST = K-K1
ID = IPIV(KST)-KST
KST = (KR-J) * L
DO 65K=1,L
KST = KST + 1
H=B(KST)
II = KST
DO 60I=JST,IEND
II = II + L
60 H = H - A(I) * X(II)
II = KST + ID *L
X(KST) = X(II)
X(II) = PIV * H
65 CONTINUE
70 IST = KT*L
DO 80J=1,L
IST = IST + 1
H = 0.
JA = IST
IF (M.LE.KT) GO TO 80
NR = M - KT
IF (NR.EQ.1) GO TO 75
CALL TLSMSQ (B(IST),L,NR,H)
GO TO 80
75 H = B(IST)*B(IST)
80 AUX(J) = H
RETURN
90 IER = -1001
RETURN
END
The problem is that slate.k (aka prephitmp.78) is read before it is stored,
so it has the 0x20202020 value instead of 1.
At tlsc.f.198r.compgotos the code still looks correct:
(insn 1857 1434 1443 8 tlsc.f:16 (set (reg:SI 14 r14 [1392])
(const_int 1 [0x1])) 4 {*movsi_internal} (expr_list:REG_EQUIV
(const_int 1 [0x1])
(nil)))
(insn 1443 1857 242 8 tlsc.f:16 (set (mem/s/c:SI (post_modify:DI (reg/f:DI 53
r59 [1516])
(plus:DI (reg/f:DI 53 r59 [1516])
(const_int -60 [0xffc4]))) [2 slate.k+0 S4
A32])
(reg:SI 14 r14 [1392])) 4 {*movsi_internal} (expr_list:REG_INC
(reg/f:DI 53 r59 [1516])
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil
...
(insn 197 228 247 8 tlsc.f:17 (set (reg:DI 18 r18)
(zero_extend:DI (mem/s/c:SI (reg/f:DI 38 r44 [1517]) [2 slate.k+0 S4
A32]))) 103 {zero_extendsidi2} (expr_list:REG_EQUAL
(mem/s/c:SI (const:DI (plus:DI (symbol_ref:DI (slate_) var_decl
0x23c54c80 slate)
(const_int 60 [0x3c]))) [2 slate.k+0 S4 A32])
(nil)))
(insn 247 197 198 8 tlsc.f:22 (set (reg:SI 19 r19 [665])
(minus:SI (reg:SI 20 r20 [orig:560 D.775 ] [560])
(reg:SI 32
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #14 from jakub at gcc dot gnu dot org 2008-06-25 11:31 ---
I have no idea why is speculation even attempted here (it doesn't make any
sense,
the pointer is surely non-NULL, it points to a global variable), and apparently
nothing checks whether it is safe to move over the speculative load over
the store (at least, I've put a breakpoint on nonoverlapping_memrefs_p
and {{,canon_}true,anti,output}_dependence and none of them hit with any MEMs
with r44 or POST_MODIFY r59, -60. Maxim, speculation is your baby, could you
please have a look?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||mkuvyrkov at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #15 from jakub at gcc dot gnu dot org 2008-06-25 11:32 --- Wrong-code bug on secondary arch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug target/36613] [4.1/4.2/4.3/4.4 Regression] likely codegen bug
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-06-25 11:51 --- Wrong code on primary arch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
[Bug target/35366] [4.4 Regression] gfortran.dg/equiv_7.f90 fails with -m64 -Os on powerpc-apple-darwin9
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35366
[Bug middle-end/35412] Correctness with -ftrapv depended on libcall notes
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-06-25 11:54 --- Not a regression. $Summary was true always. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4 Regression] Correctness|Correctness with -ftrapv |with -ftrapv depended on|depended on libcall notes |libcall notes | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
[Bug bootstrap/35619] [4.3/4.4 Regression] fixed includes not being found if building in src dir
--- Comment #20 from rguenth at gcc dot gnu dot org 2008-06-25 11:57
---
Actually we made it work at some point and that is even documented:
First, we @strong{highly} recommend that GCC be built into a
separate directory than the sources which does @strong{not} reside
within the source tree. This is how we generally build GCC; building
where @var{srcdir} == @var{objdir} should still work, but doesn't
get extensive testing; building where @var{objdir} is a subdirectory
of @var{srcdir} is unsupported.
but lowering priority according to the strong suggestion in the docs.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35619
[Bug target/36613] [4.1/4.2/4.3/4.4 Regression] likely codegen bug
--- Comment #6 from jakub at gcc dot gnu dot org 2008-06-25 12:00 ---
Simplified testcase (fails at -Os -m32):
/* PR target/36613 */
extern void abort (void);
static inline int
lshifts (int val, int cnt)
{
if (val 0)
return val;
return val cnt;
}
static inline unsigned int
lshiftu (unsigned int val, unsigned int cnt)
{
if (cnt = sizeof (unsigned int) * __CHAR_BIT__
|| val ((__INT_MAX__ * 2U) cnt))
return val;
return val cnt;
}
static inline int
rshifts (int val, unsigned int cnt)
{
if (val 0 || cnt = sizeof (int) * __CHAR_BIT__)
return val;
return val cnt;
}
int
foo (unsigned int val)
{
return rshifts (1 + val, lshifts (lshiftu (val, val), 1));
}
int
main (void)
{
if (foo (1) != 0)
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
[Bug middle-end/36037] [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-06-25 12:01 --- It looks like you run out of stack space during GC walk. You can check if so by raising the stack limit with 'ulimit -s unlimited'. I recall that Jakub had a patch to limit recursion in GC somewhat? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36037
[Bug ada/36207] [4.4 regression] Ada bootstrap fails in uintp.adb:1595
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36207
[Bug middle-end/36315] [4.4 Regression] ICE with -fprofile-use (Invalid read of size 8)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36315
[Bug middle-end/36037] [4.4 regression] segfault in gt_ggc_mx_dw_loc_descr_struct
--- Comment #7 from jakub at gcc dot gnu dot org 2008-06-25 12:06 --- That was PR36060 and is already fixed in 4.3/4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36037
[Bug libmudflap/36397] [4.4 regression] ICE with pointer cast and -fmudflap
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36397
[Bug c++/36411] [4.4 regression] ICE with invalid template template parameter
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36411
[Bug testsuite/36440] [4.4 Regression] FAIL: g++.dg/cdce3.C on powerpc-apple-darwin8.5.0
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36440
[Bug middle-end/36444] [4.4 Regression] ICE in gen_lowpart_general with -O1 with vector registers
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36444
[Bug middle-end/36445] [4.4 Regression] ICE in expand_expr_real_1 with -O1 with vector registers
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36445
[Bug target/36450] [4.4 Regression] ICE in insert_restore/insert_save with GET_MODE_ALIGNMENT mem
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36450
[Bug testsuite/36458] [4.4 Regression] Invalid fortran-torture -msse2 tests on Athlon XP
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36458
[Bug fortran/36463] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7264 with rev.136554
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36463
[Bug middle-end/36509] [4.4 Regression]: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||diagnostic Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36509
[Bug tree-optimization/36511] [4.4 Regression] ice for legal code with -O2
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36511
[Bug middle-end/36554] [4.4 regression] verify_flow_info ICE can not throw but has EH edges
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-25 12:12 --- C testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36554
[Bug c/36629] New: ICE in _lshrdi3 when compiling 06/20/08 snapshot on x86_64
When I attempt to compile the 06/20/08 snapshot of gcc on an x86_64 system under SuSE Linux 10.0 I get the following error: /home/mrichmon/gcc-4.4-20080620/g95/./gcc/xgcc -B/home/mrichmon/gcc-4.4-20080620/g95/./gcc/ -B/home/mrichmon/irun/x86_64-unknown-linux-gnu/bin/ -B/home/mrichmon/irun/x86_64-unknown-linux-gnu/lib/ -isystem /home/mrichmon/irun/x86_64-unknown-linux-gnu/include -isystem /home/mrichmon/irun/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I/home/mrichmon/gcc-4.4-20080620/libgcc -I/home/mrichmon/gcc-4.4-20080620/libgcc/. -I/home/mrichmon/gcc-4.4-20080620/libgcc/../gcc -I/home/mrichmon/gcc-4.4-20080620/libgcc/../include -I/home/mrichmon/gcc-4.4-20080620/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DUSE_TLS -o _lshrdi3.o -MT _lshrdi3.o -MD -MP -MF _lshrdi3.dep -DL_lshrdi3 -c /home/mrichmon/gcc-4.4-20080620/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS /home/mrichmon/gcc-4.4-20080620/libgcc/../gcc/libgcc2.c: In function â__lshrdi3â: /home/mrichmon/gcc-4.4-20080620/libgcc/../gcc/libgcc2.c:413: 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. make[5]: *** [_lshrdi3.o] Error 1 -- Summary: ICE in _lshrdi3 when compiling 06/20/08 snapshot on x86_64 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36629
[Bug tree-optimization/36630] New: [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer
void
foo (unsigned char *x, short y)
{
short i;
i = 2;
while (i y)
{
x[i - 1] = x[i];
i = i + 1;
}
}
ICEs at -O3 on x86_64-linux in 4.3/4.4, works in 4.2 with -O3 -ftree-vectorize.
--
Summary: [4.3/4.4 Regression] ICE in
vect_update_ivs_after_vectorizer
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36630
[Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36630
[Bug target/36627] X86: wrong mode in subqi_2
--- Comment #2 from ubizjak at gmail dot com 2008-06-25 13:40 ---
(In reply to comment #1)
Confirmed. Looks like a cutpaste error. Uros?
Indeed: I'm testing following patch:
Index: i386.md
===
--- i386.md (revision 137106)
+++ i386.md (working copy)
@@ -7533,7 +7533,7 @@
(define_insn *subqi_1
[(set (match_operand:QI 0 nonimmediate_operand =qm,q)
(minus:QI (match_operand:QI 1 nonimmediate_operand 0,0)
- (match_operand:QI 2 general_operand qn,qmn)))
+ (match_operand:QI 2 general_operand qn,qm)))
(clobber (reg:CC FLAGS_REG))]
ix86_binary_operator_ok (MINUS, QImode, operands)
sub{b}\t{%2, %0|%0, %2}
@@ -7543,7 +7543,7 @@
(define_insn *subqi_1_slp
[(set (strict_low_part (match_operand:QI 0 nonimmediate_operand +qm,q))
(minus:QI (match_dup 0)
- (match_operand:QI 1 general_operand qn,qmn)))
+ (match_operand:QI 1 general_operand qn,qm)))
(clobber (reg:CC FLAGS_REG))]
(! TARGET_PARTIAL_REG_STALL || optimize_size)
!(MEM_P (operands[0]) MEM_P (operands[1]))
@@ -7555,10 +7555,10 @@
[(set (reg FLAGS_REG)
(compare
(minus:QI (match_operand:QI 1 nonimmediate_operand 0,0)
- (match_operand:QI 2 general_operand qi,qm))
+ (match_operand:QI 2 general_operand qn,qm))
(const_int 0)))
- (set (match_operand:HI 0 nonimmediate_operand =qm,q)
- (minus:HI (match_dup 1) (match_dup 2)))]
+ (set (match_operand:QI 0 nonimmediate_operand =qm,q)
+ (minus:QI (match_dup 1) (match_dup 2)))]
ix86_match_ccmode (insn, CCGOCmode)
ix86_binary_operator_ok (MINUS, QImode, operands)
sub{b}\t{%2, %0|%0, %2}
@@ -7568,9 +7568,9 @@
(define_insn *subqi_3
[(set (reg FLAGS_REG)
(compare (match_operand:QI 1 nonimmediate_operand 0,0)
-(match_operand:QI 2 general_operand qi,qm)))
- (set (match_operand:HI 0 nonimmediate_operand =qm,q)
- (minus:HI (match_dup 1) (match_dup 2)))]
+(match_operand:QI 2 general_operand qn,qm)))
+ (set (match_operand:QI 0 nonimmediate_operand =qm,q)
+ (minus:QI (match_dup 1) (match_dup 2)))]
ix86_match_ccmode (insn, CCmode)
ix86_binary_operator_ok (MINUS, QImode, operands)
sub{b}\t{%2, %0|%0, %2}
BTW: I don't think that i makes sense here. I guess that i.e. sbb $.Lx, %al
will upset the assembler with immediate operand out of range.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36627
[Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-06-25 14:27 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-25 14:27:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36630
[Bug c++/36631] New: [4.3 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
The following code generates a recursive inlining error in 4.3.[01] while it
did not in 4.[12]. Somehow, the bug requires having both always_inline
attributes.
templatetypename T
struct B {
struct C {
__attribute__((always_inline)) C(C const c)
{
}
};
void __attribute__((always_inline)) g(C c)
{
}
};
void trigger(Bint b, Bint::C c)
{
b.g(c);
}
Cleanup4.ii: In function 'void trigger(Bint, Bint::C)':
Cleanup4.ii:8: sorry, unimplemented: inlining failed in call to 'void
BT::g(BT::C) [with T = int]': recursive inlining
Cleanup4.ii:15: sorry, unimplemented: called from here
--
Summary: [4.3 Regression] attribute always_inline - sorry,
unimplemented: recursive inlining
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: josep dot m dot perez at bsc dot es
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36631
[Bug fortran/36632] New: OpenMP code segment with module variable causes Fortran compiler to crash
This testcase causes GNU Fortran versions shown below (as far as I know): 4.2.1 4.3.0 to crash with `internal compiler error'. This testcase shows some features that must exist in order to cause the compiler to fail: - inside the OpenMP section, it accesses a module variable (ModuleVar) - the enclosing subroutine (named `crash' in the testcase) contains one or more nested subroutines/functions. If NO nested subroutine is defined inside the function, then all is OK. Some invariants: - the !$omp master directive is optional; the crash occurs regardless whether it is present. - the access mode of ModuleVar does not matter--it can be a write or a read - the `subroutine' keyword can be replaced with `program', and it still crashes. Here's the gfortran output: $ gfortran -c -fopenmp crash.f95 crash.f95:39: 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. $ /usr/local/gcc-4.3.0/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 -fopenmp crash.f95 crash blah crash.f95: At top level: crash.f95:39: 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. Here's the debugging output: $ gdb /usr/local/gcc-4.3.0/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu... Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (gdb) run -fopenmp crash.f95 Starting program: /usr/local/gcc-4.3.0/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 -fopenmp crash.f95 crash blah Program received signal SIGSEGV, Segmentation fault. get_frame_type (info=0x0) at ../../gcc-4.3.0/gcc/tree-nested.c:198 198 tree type = info-frame_type; (gdb) where #0 get_frame_type (info=0x0) at ../../gcc-4.3.0/gcc/tree-nested.c:198 #1 0x082be86f in get_chain_decl (info=0x87ab180) at ../../gcc-4.3.0/gcc/tree-nested.c:304 #2 0x082bf872 in get_nonlocal_debug_decl (info=0x87ab180, decl=0xb7caa1b8) at ../../gcc-4.3.0/gcc/tree-nested.c:904 #3 0x082c11e4 in convert_nonlocal_omp_clauses (pclauses=value optimized out, wi=0xbfe1bfbc) at ../../gcc-4.3.0/gcc/tree-nested.c:1181 #4 0x082c0e99 in convert_nonlocal_reference (tp=0xb7ccd5fc, walk_subtrees=0xbfe1bec8, data=0xbfe1bfbc) at ../../gcc-4.3.0/gcc/tree-nested.c:1099 #5 0x08382e8d in walk_tree_1 (tp=0xb7ccd5fc, func=0x82c0c80 convert_nonlocal_reference, data=0xbfe1bfbc, pset=0x0, lh=0) at ../../gcc-4.3.0/gcc/tree.c:8391 #6 0x082bfd30 in walk_stmts (wi=0xbfe1bfbc, tp=0xb7ccd5fc) at ../../gcc-4.3.0/gcc/tree-nested.c:640 #7 0x082bfefd in walk_stmts (wi=0xbfe1bfbc, tp=0xb7cab0e8) at ../../gcc-4.3.0/gcc/tree-nested.c:575 #8 0x082bfd78 in walk_stmts (wi=0xbfe1bfbc, tp=0xb7cd7d08) at ../../gcc-4.3.0/gcc/tree-nested.c:594 #9 0x082bffab in walk_body (callback=0x82c0c80 convert_nonlocal_reference, info=0x0, stmt_p=0xb7caa1b8) at ../../gcc-4.3.0/gcc/tree-nested.c:657 #10 0x082bffed in walk_all_functions (callback=0x82c0c80 convert_nonlocal_reference, root=0x87ab180) at ../../gcc-4.3.0/gcc/tree-nested.c:665 #11 0x082c00ca in lower_nested_functions (fndecl=0xb7cd7cb0) at ../../gcc-4.3.0/gcc/tree-nested.c:2001 #12 0x083cec09 in cgraph_finalize_function (decl=0xb7cd7cb0, nested=0 '\0') at ../../gcc-4.3.0/gcc/cgraphunit.c:620 #13 0x080de9bf in gfc_generate_function_code (ns=0x87aaa38) at ../../gcc-4.3.0/gcc/fortran/trans-decl.c:3376 #14 0x0809bdad in gfc_parse_file () at ../../gcc-4.3.0/gcc/fortran/parse.c:3579 #15 0x080c71c5 in gfc_be_parse_file (set_yydebug=0) at ../../gcc-4.3.0/gcc/fortran/f95-lang.c:260 #16 0x0828ef04 in toplev_main (argc=3, argv=0xbfe1c334) at ../../gcc-4.3.0/gcc/toplev.c:1042 #17 0x0810145f in main (argc=150994976, argv=0x0) at ../../gcc-4.3.0/gcc/main.c:35 Note that I built my own GCC on an Intel Pentium M laptop with Ubuntu 7.04 Linux, and using gmp version 4.2.2 and mpfr 2.3.1 . -- Summary: OpenMP code segment with module variable causes Fortran compiler to crash Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wirawan0 at gmail dot com 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=36632
[Bug fortran/36632] OpenMP code with access to module variable causes Fortran compiler to crash
--- Comment #1 from wirawan0 at gmail dot com 2008-06-25 19:25 --- Created an attachment (id=15813) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15813action=view) Fortran95 source code No postprocessing needed. To reproduce the error, use: gfortran -c -fopenmp crash.f95 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36632
[Bug middle-end/36554] [4.4 regression] verify_flow_info ICE can not throw but has EH edges
--- Comment #2 from laurent at guerby dot net 2008-06-25 20:04 --- To my knowledge there's no exception in C and I know next to nothing in C++ so I unfortunately can't contribute a c++ testcase. May be Eric can help? -- laurent at guerby dot net changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36554
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #22 from aoliva at gcc dot gnu dot org 2008-06-25 20:20 --- Sorry that it took me so long to look at this. Richi, I have a feeling that your patch will just paper over the problem. See, if we take a bit-range that's not the entire bit-field, it will emit the same shifts, and it will break in the same way. The problem is that there's a disconnect between the width of the underlying mode/type and the width of the variable in which it is held. When I introduced bit-fields in SRA, one of my goals was to introduce scalars for remaining fields (i.e., those that didn't get scalar versions of their own) in such a way that no extraneous shifting was needed: we'd just extract the bits without shifting them around, for this would be just wasted computation. It sufficed to apply masks to recombine these remaining fields into their proper place. Now, when you changed type from a mode-sized type to a nonstandard bitfield-sized type and replaced some bitfield references with plain conversions, you broke this property and removed the fix-ups that would have taken care of ensuring the shifts (if any) matched. At least that's my impression from looking at the dumps posted here, your recent patch to work around the exposed problem and your earlier patch that introduced it. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug middle-end/36633] New: warning array subscript is below array bounds on delete [] with -O2, -Wall
When deleting an array of dynamically allocated objects that inherit some base class, a pointer offset calculation is modified during the optimization process of a delete [] operator. The result is a subscript operation with a negative index and this causes the warning to be emitted (erroneously I believe). This was determined by analyzing the tree dump. The file move_array.cpp.059t.dce2 has this code: D.2208_15 = D.2171_6 + -8; operator delete [] (D.2208_15); turn into this in move_array.cpp.060t.forwprop2: D.2208_15 = (*D.2149_3)[-8]; operator delete [] (D.2208_15); -- Summary: warning array subscript is below array bounds on delete [] with -O2, -Wall Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris dot fairles at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug middle-end/36633] warning array subscript is below array bounds on delete [] with -O2, -Wall
--- Comment #1 from chris dot fairles at gmail dot com 2008-06-25 20:53 --- Created an attachment (id=15814) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15814action=view) Test case that issues warning with compiling with -O2,-Wall -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug middle-end/36633] warning array subscript is below array bounds on delete [] with -O2, -Wall
--- Comment #2 from chris dot fairles at gmail dot com 2008-06-25 20:54 --- Created an attachment (id=15815) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15815action=view) File from tree dump before subscript operator appears. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug middle-end/36633] warning array subscript is below array bounds on delete [] with -O2, -Wall
--- Comment #3 from chris dot fairles at gmail dot com 2008-06-25 20:55 --- Created an attachment (id=15816) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15816action=view) File from tree dump with the negative subscript index -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug middle-end/36633] warning array subscript is below array bounds on delete [] with -O2, -Wall
--- Comment #4 from chris dot fairles at gmail dot com 2008-06-25 20:56 --- Adding CC as requested. -- chris dot fairles at gmail dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug middle-end/36633] warning array subscript is below array bounds on delete [] with -O2, -Wall
--- Comment #5 from chris dot fairles at gmail dot com 2008-06-25 20:59 --- This bug is similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35593 which is fixed in mainline. -- chris dot fairles at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug c++/36633] warning array subscript is below array bounds on delete [] with -O2, -Wall
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-06-25 20:59 --- D.2148_2 = (struct D[7] *) D.2168_1; D.2149_3 = D.2148_2 + 8; D.2169_4 = (long unsigned int *) D.2149_3; D.2170_5 = D.2169_4 + -8; That seems wrong. Why are we going from a struct D[7] * to a long unsigned int * ? In fact I think this is a bug in the C++ front-end really. It is producing weird types with respect of operator new[] in the first place. the first 8 bytes is the size but casts the resulting of operator new first to struct D[7] * and then does an add, that seems wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|middle-end |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug c++/36633] warning array subscript is below array bounds on delete [] with -O2, -Wall
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-06-25 21:00 --- (In reply to comment #5) This bug is similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35593 which is fixed in mainline. It is like that but this one is really the C++ front-end emitting weird trees to begin with which is confusing the rest of the middle-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug target/36627] X86: wrong mode in subqi_2
--- Comment #3 from uros at gcc dot gnu dot org 2008-06-25 21:07 --- Subject: Bug 36627 Author: uros Date: Wed Jun 25 21:06:20 2008 New Revision: 137122 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137122 Log: PR target/36627 * config/i386/i386.md : Change constraints of HImode and QImode immediate operands from i to n. Change SImode ni constraint to i and SImode rmi constraint to g. Remove all constraints from const0_operand and const1_operand predicated operands. (i): Change QImode and HImode attribute from i to n. (*subqi_2): Change HImode operands to QImode. (*subqi_3): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36627
[Bug target/36627] X86: wrong mode in subqi_2
--- Comment #4 from ubizjak at gmail dot com 2008-06-25 21:09 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||06/msg01596.html Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36627
[Bug middle-end/36554] [4.4 regression] verify_flow_info ICE can not throw but has EH edges
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-06-25 21:11 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-25 21:11:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36554
[Bug c++/36633] [4.4 regression] warning array subscript is below array bounds on delete [] with -O2, -Wall
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-06-25 21:24:20 date|| Summary|warning array subscript is |[4.4 regression] warning |below array bounds on |array subscript is below |delete [] with -O2, -Wall |array bounds on delete [] ||with -O2, -Wall http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36633
[Bug target/36634] New: -msecure-plt combine gives invalid call insn
The -msecure-plt ABI requires that -fpic/-fPIC calls via the PLT have the GOT
pointer register valid. gcc accomplishes this by adding pic_offset_table_rtx
to CALL_INSN_FUNCTION_USAGE for such calls at rtl expansion time. See
rs6000.md define_expand call. Now, indirect calls do *not* need a GOT
pointer since they don't go via the PLT, and we wouldn't want indirect calls to
cause unnecessary code in a function prologue to set up the GOT pointer. This
is a lurking problem for the RTL combiner if it should happen to see an
opportunity to combine an instruction loading a function pointer followed by an
indirect call, since it will combine them to a PLT call that lacks a use of
pic_offset_table_rtx.
$ cat pr44759.c
#include stdio.h
#include stdlib.h
extern void first_call (void);
int main (void)
{
first_call ();
printf (All finished\n);
}
$ cat pr44759-1.c
#include stdio.h
#include stdlib.h
typedef void (*simple) (signed int);
void myprint (unsigned int i)
{
printf(I am printing\n);
}
static inline void lets_inline (void (*p)(signed int), int v)
{
(*p)(v);
}
void first_call (void)
{
lets_inline ((simple)myprint, 0);
}
$ gcc -c pr44759.c -fPIC -O2 -msecure-plt
$ gcc -c pr44759-1.c -fPIC -O2 -msecure-plt
$ gcc -o libpr44759.so pr44759-1.o -fPIC -shared -msecure-plt
$ gcc -o pr44759 pr44759.o libpr44759.so
$ LD_LIBRARY_PATH=. ./pr44759
Segmentation fault
Note that the testcase does not fail on mainline or gcc-4.3, presumably because
combining happens at the tree level there. I'm also not sure whether the
testcase is completely valid code, but even if not, there may be other ways to
expose the rtl combine error.
--
Summary: -msecure-plt combine gives invalid call insn
Product: gcc
Version: 4.1.3
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amodra at bigpond dot net dot au
GCC target triplet: powerpc-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
[Bug target/36634] -msecure-plt combine gives invalid call insn
-- amodra at bigpond dot net dot au changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net |dot org |dot au Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.1.3 4.2.5 Last reconfirmed|-00-00 00:00:00 |2008-06-25 21:30:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36634
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #16 from mkuvyrkov at gcc dot gnu dot org 2008-06-25 21:33 --- I can't reproduce the error with today mainline. When I put in one file 'PROGRAM PR35659' and 'SUBROUTINE TLSC (A,B,AUX,IPIV,EPS,X)' and compile it with any optimization level I get the same STOP 0 message. Am I doing something wrong? I can't spot the problem in the dumps you posted at debian.org. tlsc.s has a single example of data speculation which seems to be fine. Scheduler speculatively moves ld4.a r18 = [r44] before st4 [r59] = r14, -60 and then also speculates several uses of r18: cmp4.ge p6, p7 = r22, r18 ... (p7) ld4 r14 = [r62] ... (p7) st4 [r77] = r14 then it checks the speculation: chk.a.clr r18, .L69 and recovers if speculation failed: .L69: .mmi ld4 r18 = [r44] ;; cmp4.ge p6, p7 = r22, r18 nop 0 ;; .mmi nop 0 (p7) ld4 r14 = [r62] nop 0 ;; .mib (p7) st4 [r77] = r14 nop 0 br .L70 Anyway, can you help me reproduce the issue, so I can take a closer look? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #23 from rguenther at suse dot de 2008-06-25 21:48 --- Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above On Wed, 25 Jun 2008, aoliva at gcc dot gnu dot org wrote: --- Comment #22 from aoliva at gcc dot gnu dot org 2008-06-25 20:20 --- Sorry that it took me so long to look at this. Richi, I have a feeling that your patch will just paper over the problem. I know. See, if we take a bit-range that's not the entire bit-field, it will emit the same shifts, and it will break in the same way. The problem is that there's a disconnect between the width of the underlying mode/type and the width of the variable in which it is held. When I introduced bit-fields in SRA, one of my goals was to introduce scalars for remaining fields (i.e., those that didn't get scalar versions of their own) in such a way that no extraneous shifting was needed: we'd just extract the bits without shifting them around, for this would be just wasted computation. It sufficed to apply masks to recombine these remaining fields into their proper place. Now, when you changed type from a mode-sized type to a nonstandard bitfield-sized type and replaced some bitfield references with plain conversions, you broke this property and removed the fix-ups that would have taken care of ensuring the shifts (if any) matched. The _result_ type is what I changed. The result type of a BIT_FIELD_REF needs to match the bitfield width. If you can point out where I changed the field type that is referenced then you have found the error. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug middle-end/28831] [4.1/4.2/4.3/4.4 Regression] Aggregate copy not elided when using a return value as a pass-by-value parameter
--- Comment #5 from jason at gcc dot gnu dot org 2008-06-25 21:49 ---
Here's another example:
struct A { int i[100]; };
void f(struct A);
int main()
{
f((struct A){1});
}
Here we build up the compound literal on the stack and then copy it into the
argument slot.
This seems to be a problem with GIMPLE, as there's no way to represent that we
want a particular temporary object to live in the argument slot.
This is both more and less of a problem for C++, as it has many more temporary
struct objects, but also has pass-by-reference (and the ABI does transparent
pass-by-reference for non-POD structs).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28831
[Bug c/36635] New: cc1 segfault from svn 137122
[EMAIL PROTECTED] tmp31]$ current-gcc -O3 small.c
current-gcc: Internal error: Segmentation fault (program cc1)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[EMAIL PROTECTED] tmp31]$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr
Thread model: posix
gcc version 4.4.0 20080625 (experimental) (GCC)
[EMAIL PROTECTED] tmp31]$ cat small.c
typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
static inline unsigned int
lshift_u_u (unsigned int left, unsigned int right)
{
if ((right = sizeof (unsigned int))
|| (left ((2147483647 * 2U + 1U) right)))
return left;
}
static inline unsigned long int
mod_rhs (const long int rhs)
{
return rhs;
}
static inline unsigned long int
div_rhs (const long int rhs)
{
return rhs;
}
uint32_t g_22;
int32_t
func_53 (uint32_t p_54, uint32_t p_55, uint32_t p_56, uint8_t p_57)
{
int32_t l_58 = 0xB8BF5144L;
for (0; 1; p_56 -= 0)
{
uint32_t l_59 = -1L;
if (((lshift_u_u ((g_22 / div_rhs (l_58)), (1 % mod_rhs (l_59))
return 1;
for (l_59 = 0; (l_59 = -20); l_59 += 1)
{
}
}
}
--
Summary: cc1 segfault from svn 137122
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah 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=36635
[Bug target/35659] [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64
--- Comment #17 from doko at cs dot tu-berlin dot de 2008-06-25 22:16 --- Subject: Re: [4.3/4.4 Regression] Miscompiled code with -O2 (but not with -O2 -funroll-loops) on ia64 mkuvyrkov at gcc dot gnu dot org writes: Anyway, can you help me reproduce the issue, so I can take a closer look? please email me a ssh key, if access to a Debian machine would help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35659
[Bug fortran/36526] pointer in pure function
--- Comment #3 from pault at gcc dot gnu dot org 2008-06-25 23:05 --- Subject: Bug 36526 Author: pault Date: Wed Jun 25 23:04:33 2008 New Revision: 137125 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137125 Log: 2008-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/36526 * interface.c (check_intents): Correct error where the actual arg was checked for a pointer argument, rather than the formal. 2008-06-25 Paul Thomas [EMAIL PROTECTED] PR fortran/36526 * gfortran.dg/proc_formal_proc_2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pure_formal_proc_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36526
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #24 from aoliva at gcc dot gnu dot org 2008-06-26 00:33 --- It's not just the result type that changed. You actually changed the type of the variable created to hold the group of bit fields, out of which we further extract members that were not mapped to separate variables. This might affect bitfield simplifications based on mode size rather than type width. I can't say that's it, but I know I may have based some code on this assumption that you broke. It also seems to me that this change to the base type of the variable breaks sra_build_elt_assignment(), because the by-design conditions might no longer be met. Finally, I don't see how you could assume that the else block for the if full-width bit-field could be extracted with as little as a cast. This is what jumped at me at first. I haven't actually built compilers based on the state before and after your patch to tell whether that's it, but these are the most likely culprits. I hope this helps, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug ada/36638] New: c34008: Program received signal SIGILL, Illegal instruction
Starting program: /xxx/gnu/gcc/objdir/gcc/testsuite/ada/acats/tests/c3/c34008a/c34008a ,.,. C34008A ACATS 2.5 08-06-25 20:53:12 C34008A CHECK THAT THE REQUIRED PREDEFINED OPERATIONS ARE DECLARED (IMPLICITLY) FOR DERIVED TASK TYPES. C34008A PASSED . Program received signal SIGILL, Illegal instruction. 0x7b037054 in ?? () (gdb) bt #0 0x7b037054 in ?? () #1 0x0003c71c in _Unwind_SjLj_RaiseException (exc=0x40036d70) at ../../../gcc/libgcc/../gcc/unwind.inc:118 Breakpoint 1, 0x0003c714 in _Unwind_SjLj_RaiseException (exc=0x40036d70) at ../../../gcc/libgcc/../gcc/unwind.inc:118 118 code = (*fs.personality) (1, _UA_SEARCH_PHASE, exc-exception_class, (gdb) bt #0 0x0003c714 in _Unwind_SjLj_RaiseException (exc=0x40036d70) at ../../../gcc/libgcc/../gcc/unwind.inc:118 #1 0x00039b60 in __gnat_Unwind_RaiseException (e=0x1) at raise-gcc.c:1158 #2 0x00025978 in ada__exceptions__exception_propagation__propagate_exceptionXn (e=0x1, from_signal_handler=true) at a-exexpr.adb:589 #3 0x00026734 in __gnat_raise_nodefer_with_msg (e=0x400334b0) at a-except.adb:829 #4 0x000267b0 in __gnat_raise_exception (e=0x40001a1c) at a-except.adb:868 #5 0x00018e50 in system__tasking__initialization__do_pending_action ( self_id=0x40033380) at s-tasini.adb:271 #6 0x00018ea4 in system__tasking__initialization__undefer_abort_nestable ( self_id=0x0) at s-tasini.adb:660 #7 0x00031984 in system__tasking__rendezvous__selective_wait ( select_mode=system__tasking__terminate_mode) at s-tasren.adb:944 #8 0x000361a8 in c34008a__pkg__parentB.2206 () #9 0x000339f0 in system__tasking__stages__task_wrapper (self_id=0x40033380) at s-tassta.adb:1151 #10 0x7ae76d28 in cma__thread_base () from /usr/lib/libcma.1 #11 0x7ae7b8e8 in cma__thread_start1 () from /usr/lib/libcma.1 fs.personality seems wrong causing a jump to random data. -- Summary: c34008: Program received signal SIGILL, Illegal instruction Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36638
[Bug inline-asm/36639] New: pointer referenced in asm statement not regarded as VUSE
This is originally derived from code from Linux, in which the physical address
of a structure is passed to an asm statement as an integral type, causing the
initializer of the structure to be optimized away.
int main() { int i = 0x12345678; long j = (long)i; asm (# %0 : : r (j)); }
int main() { int i = 0x12345678; void *j = i; asm (# : : p (j)); }
At the very least in the second case above, the compiler should mark the asm
statement as a VUSE of i. Arguably, it should do so in the former case as
well, like it does for pointers passed to function calls as integral types.
--
Summary: pointer referenced in asm statement not regarded as VUSE
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aoliva at gcc dot gnu dot org
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36639
Re: [Bug inline-asm/36639] New: pointer referenced in asm statement not regarded as VUSE
This is correct as you are just using the address and not the contents
itself. This is how inline-asm is documented to work also.
-- Andrew Pinski
Sent from my iPhone
On Jun 25, 2008, at 19:08, aoliva at gcc dot gnu dot org [EMAIL PROTECTED]
wrote:
This is originally derived from code from Linux, in which the
physical address
of a structure is passed to an asm statement as an integral type,
causing the
initializer of the structure to be optimized away.
int main() { int i = 0x12345678; long j = (long)i; asm (# %0 : :
r (j)); }
int main() { int i = 0x12345678; void *j = i; asm (# : :
p (j)); }
At the very least in the second case above, the compiler should mark
the asm
statement as a VUSE of i. Arguably, it should do so in the former
case as
well, like it does for pointers passed to function calls as integral
types.
--
Summary: pointer referenced in asm statement not regarded
as VUSE
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aoliva at gcc dot gnu dot org
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36639
[Bug inline-asm/36639] pointer referenced in asm statement not regarded as VUSE
--- Comment #1 from pinskia at gmail dot com 2008-06-26 03:46 ---
Subject: Re: New: pointer referenced in asm statement not regarded as VUSE
This is correct as you are just using the address and not the contents
itself. This is how inline-asm is documented to work also.
-- Andrew Pinski
Sent from my iPhone
On Jun 25, 2008, at 19:08, aoliva at gcc dot gnu dot org
[EMAIL PROTECTED]
wrote:
This is originally derived from code from Linux, in which the
physical address
of a structure is passed to an asm statement as an integral type,
causing the
initializer of the structure to be optimized away.
int main() { int i = 0x12345678; long j = (long)i; asm (# %0 : :
r (j)); }
int main() { int i = 0x12345678; void *j = i; asm (# : :
p (j)); }
At the very least in the second case above, the compiler should mark
the asm
statement as a VUSE of i. Arguably, it should do so in the former
case as
well, like it does for pointers passed to function calls as integral
types.
--
Summary: pointer referenced in asm statement not regarded
as VUSE
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aoliva at gcc dot gnu dot org
GCC build triplet: *-*-*
GCC host triplet: *-*-*
GCC target triplet: *-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36639
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36639
[Bug inline-asm/36639] pointer referenced in asm statement not regarded as VUSE
--- Comment #2 from aoliva at gcc dot gnu dot org 2008-06-26 05:12 --- It is indeed documented that way, but one gets to wonder if that's desirable. Consider that in the original testcase the pointer is converted to a physical address (integral type) that must not be dereferenced, and that integral type is then passed on to a function, that calls another function, that ultimately get the integral-typed arguments into specific registers for a syscall. The function containing the asm statement can no longer tell which arguments are pointers and which aren't, because none of them are. But, as it turns out, GCC has inlined the function containing the asm statement, as well as its caller, into the function that initialized the data structure and (in this case) converted the pointer to a physical address. If it weren't for the inlining, the alias analysis code would have kicked in and noticed that the pointer escaped in the integral argument. But because everything was inlined, no escape was detected, and the asm statement was all that referenced the pointer-then-integer, and because it was an asm statement rather than a function call, things went downhill. Why shouldn't we use the same machinery we use to notice escapes in function calls to notice escapes in asm statements? FWIW, there is a work-around: add a do-nothing asm statement that accesses the memory at the time it is converted to a physical address, but that's, well, not true, and lying to the compiler always comes back and bite us later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36639
[Bug fortran/36632] OpenMP code with access to module variable causes Fortran compiler to crash
--- Comment #2 from burnus at gcc dot gnu dot org 2008-06-26 05:50 --- Fails here with 4.2 and 4.3. However, works with gfortran 4.4, which is e.g. available from http://gcc.gnu.org/wiki/GFortranBinaries -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36632
