[Bug fortran/18518] d1mach(4) (BLAS) broken, g77 regression
--- Additional Comments From c dot lemmen at fz-juelich dot de 2004-11-17 08:46 --- On AMD x32 the correct result is obtained with g77. g95 and pgfortran work as expected, only gfortran stops: gfortran d1mach.f ./a.out 2.225073858507201E-308 At line 215 of file d1mach.f STOP 778 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18518
[Bug target/18503] _mm_move_ss SSE intrinsic causes erroneous
--- Additional Comments From uros at kss-loka dot si 2004-11-17 09:17
---
The problem was that sse_movss pattern has wrong vec_merge constant, so it was
wrongly combined to vmsubv4sf3 pattern. Instead of 0x1, sse_movss pattern
should have 0x14:
(define_insn sse_movss
[(set (match_operand:V4SF 0 register_operand =x)
(vec_merge:V4SF
(match_operand:V4SF 1 register_operand 0)
(match_operand:V4SF 2 register_operand x)
(const_int 14)))] - here!
TARGET_SSE
movss\t{%2, %0|%0, %2}
[(set_attr type ssemov)
(set_attr mode SF)])
With this change, the result from your testcase is OK. ASM code looks like:
bug:
movaps %xmm0, %xmm2
subps %xmm1, %xmm2
pushl %ebp
movl %esp, %ebp
movaps %xmm2, %xmm1
movss %xmm0, %xmm1
popl %ebp
movaps %xmm1, %xmm0
ret
BTW: sse2_movsd pattern has the same problem... And sse_loadss_1,
sse_storess and their sse2 equivalents.
Bug is confirmed, a patch will follow soon...
Thanks,
Uros.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18503
[Bug target/15397] [g77] c float function called from fortran gives wrong result
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-17 09:18 --- (In reply to comment #3) I checked this with gcc-4.0-20041107 on a ia64, and the problem didn't occur: $ gfortran -v Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs Configured with: ../gcc-4.0-20041107/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 Thread model: posix gcc version 4.0.0 20041107 (experimental) $ gfortran -O test1.f funct2.c funct2.c: In function 'funct2_': funct2.c:3: warning: incompatible implicit declaration of built-in function 'printf' funct2.c: In function 'funct3_': funct2.c:8: warning: incompatible implicit declaration of built-in function 'printf' $ ./a.out funct1: return value =1.00 in test1: retval from fortran call is1.00 funct2: return value = 1.00 in test1: retval from c(float) call is1.00 funct2: return value = 2 in test1: retval from c(int) call is2 STOP 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15397
[Bug target/18503] _mm_move_ss SSE intrinsic causes erroneous
--- Additional Comments From uros at gcc dot gnu dot org 2004-11-17 09:19 --- . -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 Last reconfirmed|-00-00 00:00:00 |2004-11-17 09:19:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18503
[Bug target/18503] _mm_move_ss SSE intrinsic causes erroneous
--- Additional Comments From uros at gcc dot gnu dot org 2004-11-17 10:10 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01377.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18503
[Bug target/18506] Altivec definitions of vec_init
--- Additional Comments From dorit at il dot ibm dot com 2004-11-17 11:09 --- (In reply to comment #1) PR 10469 looks like a testcase where this could improve the code generation.\ gcc.dg/vect/vect-25.c is a testcase too. This is what is currently generated (the invariant is in r3): mr r9,r3 mr r10,r3 mr r11,r3 mr r12,r3 L6: addi r7,r1,1104 stw r9,0(r7) stw r10,4(r7) stw r11,8(r7) stw r12,12(r7) lvx v0,0,r7 stvx v0,0,r2 addi r2,r2,16 bdnz L6 instead of: stw r3,0(r2) lvewx v0,0,r2 vspltw v0,v0,0 L4: stvx v0,r2,r0 addi r2,r2,16 bdnz L4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18506
[Bug target/14010] large stack frame long double ice
--- Additional Comments From amodra at bigpond dot net dot au 2004-11-17 11:40 --- Seems to be fixed on the 3.4.x branch too. -- What|Removed |Added Status|NEW |RESOLVED Known to fail|3.4.4 | Known to work|4.0.0 |4.0.0 3.4.4 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14010
[Bug fortran/18525] New: [gfortran] ICE on invalid(?) code in gfc_get_symbol_decl()
The following testcase causes an ICE in the current gfortran. The code seems ill-formed to me, because the name n was already defined as a constant in the module scope, but I'm not sure. This was originally reported by Vivek Rao ([EMAIL PROTECTED]). module zz integer, parameter :: n=2 ! causes ICE contains subroutine xx(n) call yy(n) end subroutine xx end module zz ~/tmpgfortran -v -c bug.f90 Reading specs from /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/specs Configured with: /scratch/gcc/configure --quiet --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,f95 --with-gmp=/afs/mpa/data/martin/mygmp Thread model: posix gcc version 4.0.0 20041117 (experimental) /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/f951 bug.f90 -quiet -dumpbase bug.f90 -mtune=pentiumpro -auxbase bug -version -o /tmp/ccVLWgWD.s GNU F95 version 4.0.0 20041117 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.0 20041117 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 bug.f90: In function 'xx': bug.f90:4: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:704 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [gfortran] ICE on invalid(?) code in gfc_get_symbol_decl() Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at mpa-garching dot mpg dot de CC: gcc-bugs at gcc dot gnu dot org 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=18525
[Bug fortran/18525] [gfortran] ICE on invalid(?) code in gfc_get_symbol_decl()
-- What|Removed |Added Known to fail||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18525
[Bug target/18263] [3.4 only] Build broken for ARC.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-17 12:30 --- Subject: Bug 18263 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-11-17 12:29:17 Modified files: gcc: ChangeLog gcc/config/arc : lib1funcs.asm Log message: PR target/18263 * config/arc/lib1funcs.asm (___umulsidi3): Change use of cmp to the equivalent on the A4. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.693r2=2.2326.2.694 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arc/lib1funcs.asm.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.5.10.2r2=1.5.10.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18263
[Bug target/18263] [3.4 only] Build broken for ARC.
--- Additional Comments From giovannibajo at libero dot it 2004-11-17 12:30 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18263
[Bug fortran/18526] New: fortran testsuite broken
From a freshly extracted gcc-4.0-20041114.
make bootstrap worked like a charm. cd-ing into
the gcc subdirectory of my build directoy:
$ ./xgcc -v
Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs
Configured with: ../gcc-4.0-20041114/configure --prefix=/home/zfkts
--enable-languages=c,c++,f95
Thread model: posix
gcc version 4.0.0 20041114 (experimental)
$ make check-f95
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ../../gcc-4.0-20041114/gcc; ${PWDCMD-pwd}` ; export srcdir ; \
cd testsuite; \
EXPECT=`if [ -f ${rootme}/../expect/expect ] ; then echo ${rootme}/../expect/exp
ect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}/../expect/expect ] ; then \
TCL_LIBRARY=`cd .. ; cd ../../gcc-4.0-20041114/gcc/../tcl/library ; ${PWDCMD-
pwd}` ; \
export TCL_LIBRARY ; fi ; \
`if [ -f ${srcdir}/../dejagnu/runtest ] ; then echo ${srcdir}/../dejagnu/runtest
; else echo runtest; fi` --tool gfortran )
WARNING: Couldn't find the global config file.
Test Run By zfkts on Wed Nov 17 13:29:42 2004
Native configuration is ia64-unknown-linux-gnu
=== gfortran tests ===
Schedule of variations:
unix
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for targe
t.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/zfkts/gcc-4.0-20041114/gcc/testsuite/config/default.exp as tool-and-
target-specific interface file.
Running /home/zfkts/gcc-4.0-20041114/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/assignment_1.f90 (test for warnings, line 15)
FAIL: gfortran.dg/assignment_1.f90 (test for excess errors)
WARNING: gfortran.dg/assignment_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/assignment_1.f90 (test for warnings, line 15)
FAIL: gfortran.dg/assignment_1.f90 (test for excess errors)
WARNING: gfortran.dg/assignment_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/assignment_1.f90 (test for warnings, line 15)
FAIL: gfortran.dg/assignment_1.f90 (test for excess errors)
WARNING: gfortran.dg/assignment_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/assignment_1.f90 (test for warnings, line 15)
FAIL: gfortran.dg/assignment_1.f90 (test for excess errors)
WARNING: gfortran.dg/assignment_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/assignment_1.f90 (test for warnings, line 15)
FAIL: gfortran.dg/assignment_1.f90 (test for excess errors)
WARNING: gfortran.dg/assignment_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/assignment_1.f90 (test for warnings, line 15)
FAIL: gfortran.dg/assignment_1.f90 (test for excess errors)
WARNING: gfortran.dg/assignment_1.f90 compilation failed to produce executable
FAIL: gfortran.dg/assignment_1.f90 (test for warnings, line 15)
... and so on.
In contrast, make check-gcc works.
--
Summary: fortran testsuite broken
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: ia64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18526
[Bug c/18314] Abnormal behavior in optimization
--- Additional Comments From schwab at suse dot de 2004-11-17 13:45 --- 6.7.3#3: The properties associated with qualified types are meaningful only for expressions that are lvalues. This is not a constraint, so not an error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18314
[Bug c/18528] New: miscompilation of inline assembler with -fweb
On arm-elf-gcc, I encountered a miscompilation of inline assembly. The
miscompilation only occurs when compiled with -fweb. -fno-web makes the sample
compile correctly even with -O3 (and -fnew-ra).
Here is the configuration:
Reading specs from /home/build/gnu/lib/gcc/arm-elf/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/home/build/gnu
--target=arm-elf --disable-shared --enable-multilib --enable-interwork
--enable-languages=c --with-headers=../newlib-1.12.0/newlib/libc/include
--with-newlib
Thread model: single
gcc version 3.4.3
The bug occurs on both Cygwin and Linux hosts.
The sample case is attached inline below.
To compile the case, but the sample in test.c and run the following:
$ arm-elf-gcc -O -fweb test.c
Without -fweb:
$ arm-elf-gcc -O test.c
main() function returns zero in case of correct compilation, 2 otherwise.
ciao,
janne
# 1 test.c
# 1 built-in
# 1 command line
# 1 test.c
typedef signed int HGint32;
typedef signed long long int HGint64;
typedef union
{
struct
{
HGint32 h, l;
} c;
HGint64 r;
} HGint64_s;
HGint64 hgMax64 (HGint64 a, HGint64 b)
{
HGint64_s aa,bb;
HGint32 tmp;
aa.r = a;
bb.r = b;
asm (subs %[tmp],%[al], %[bl]\n\t sbcs %[tmp],%[ah], %[bh]\n\t movlt
%[ah], %[bh]\n\t movlt %[al], %[bl]\n\t :
[tmp] =r (tmp),
[ah] +r (aa.c.h),
[al] +r (aa.c.l) :
[bh] r (bb.c.h),
[bl] r (bb.c.l) :
cc);
return aa.r;
}
int main(void)
{
HGint64 a = 400;
HGint64 b = 100;
if(a != hgMax64(a, b))
return 2;
return 0;
}
--
Summary: miscompilation of inline assembler with -fweb
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janne at hybrid dot fi
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: arm-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18528
[Bug fortran/18526] fortran testsuite broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 12:51 --- A fall out (most likely forgotten part) when add libunwind. -- What|Removed |Added CC||hjl at lucon dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-17 12:51:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18526
[Bug c/18528] miscompilation of inline assembler with -fweb
--- Additional Comments From janne at hybrid dot fi 2004-11-17 13:52 --- Created an attachment (id=7562) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7562action=view) bug case for -fweb Sample case for -fweb bug. Just for convenience. This is the original source and not .i file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18528
[Bug tree-optimization/15484] [tree-ssa] bool and short function arguments promoted to int
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-17 13:33 --- The underlying ABI might require short bool arguments to be passed as int. Some do, some don't. Anyway, that's an argument marshalling issue, which is not currently addressed at the tree level. The cast to int has been inserted by the front end, I think C requires that. This is a VRP issue, not an argument marshalling one. -- What|Removed |Added BugsThisDependsOn||18373 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15484
[Bug tree-optimization/18527] New: Missed optimization
When loop bound condition is =, number_of_iterations_in_loop returns 'unknown'
although the loop is countable. Turns out this case is pretty common in SPEC
and blocks vectorization opportunities.
E.g.,
int foo ()
{
int a[N];
int i;
int n;
for (i = 0; i = n; i++)
{
ca[i] = 2;
}
}
In order to check loop bound for overflow (in function
number_of_iterations_exit), conditions before loop are checked (in
simplify_using_initial_conditions). However, there is no relevant condition
before the loop. The condition is n = 0 and the expression to check n !=
2147483647.
--
Summary: Missed optimization
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
CC: dorit at il dot ibm dot com,gcc-bugs at gcc dot gnu dot
org,rakdver at atrey dot karlin dot mff dot cuni dot cz
GCC build triplet: powerpc-apple-darwin7.0.0
GCC host triplet: powerpc-apple-darwin7.0.0
GCC target triplet: powerpc-apple-darwin7.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
[Bug c/18314] Abnormal behavior in optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 13:08 --- I think you want: *(volatile int*)test volatile only matters on pointers and types of variables and not casts IIRC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18314
[Bug fortran/18525] [gfortran] ICE on invalid(?) code in gfc_get_symbol_decl()
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 12:58 --- Confirmed, this is related to PR 13082. -- What|Removed |Added BugsThisDependsOn||13082 Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-17 12:58:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18525
[Bug fortran/18526] fortran testsuite broken
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-17 12:45 --- Created an attachment (id=7561) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7561action=view) log file from testsuite There appears to be some problem with loading the shared library libunwind.so.7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18526
[Bug tree-optimization/18374] [meta-bug] Argument and return value marshalling at tree level
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 13:13 --- Here is a bug which says the oposite should be done (as arguments are already done): PR 15484. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18374
[Bug tree-optimization/18519] [4.0 Regression] ICE: Segmentation fault with optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 12:46 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18519
[Bug rtl-optimization/17950] Over Aggressive Use of Data Cache Touch Instructions During FDO
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-17 14:34 --- I cannot reproduce this with the 20041118 CVS head on powerpc64-unknown-linux-gnu. Can you confirm the command line options and provide the bug.gcno, bug.gcda files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17950
[Bug rtl-optimization/17950] Over Aggressive Use of Data Cache Touch Instructions During FDO
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2004-11-17 14:41 --- Subject: Re: Over Aggressive Use of Data Cache Touch Instructions During FDO Hello, I cannot reproduce this with the 20041118 CVS head on powerpc64-unknown-linux-gnu. I think this is because speculative prefetching is now disabled by default. You should have no problems with reproducing the bug if you switch it on (-fspeculative-prefetching). Zdenek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17950
[Bug other/18508] [3.4/4.0 Regression] basename: too few arguments when building without bootstrap
-- What|Removed |Added Keywords||build Summary|basename: too few |[3.4/4.0 Regression] |arguments when building|basename: too few |without bootstrap |arguments when building ||without bootstrap Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18508
[Bug fortran/17675] [4.0 Regression] Alignment constraints not honored in EQUIVALENCE
--- Additional Comments From phython at gcc dot gnu dot org 2004-11-17 15:09 --- I'm getting the same problems on sparc32 builds. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-17 15:09:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17675
[Bug tree-optimization/18067] [4.0 Regression] ICE at loc_descriptor_from_tree_1 in dwarf2out.c (VLA)
--- Additional Comments From phython at gcc dot gnu dot org 2004-11-17 15:13 --- As Andrew mentioned, this bug affects more than powerpc. An enable-checking build is needed to reproduce this bug. With a disable-checking build the debugging code ignores SSA_NAMEs. -- What|Removed |Added GCC build triplet|ppc-linux | GCC host triplet|ppc-linux | GCC target triplet|ppc-linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18067
[Bug tree-optimization/18527] cannot determine loop bounds for loops with =
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 15:36 --- Confirmed, note PR 16803 is related (in fact when this is fixed that one should be fixed also). -- What|Removed |Added OtherBugsDependingO||16803 nThis|| Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-11-17 15:36:55 date|| Summary|Missed optimization |cannot determine loop bounds ||for loops with = http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
[Bug fortran/18525] [gfortran] ICE on invalid(?) code in gfc_get_symbol_decl()
--- Additional Comments From Thomas dot Koenig at online dot de 2004-11-17 15:39 --- The code is perfectly valid. Here, n in the subroutine hides the host parameter n (which is then inaccessible in the subroutine xx). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18525
[Bug tree-optimization/18529] New: When the lower bound of a loop is non-constant we cannot find the number of iterations
long *a;
void f(int start, int end)
{
int i;
for (i = start; i end ; i++)
a[i] = 0;
}
Some anylsis of the problem here:
http://gcc.gnu.org/ml/gcc/2004-08/msg01315.html.
I filed this to keep track of it.
--
Summary: When the lower bound of a loop is non-constant we cannot
find the number of iterations
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18529
[Bug tree-optimization/18529] When the lower bound of a loop is non-constant we cannot find the number of iterations
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 15:44 --- Note this is like PR 18527 but a different problem (I don't know how offten this shows up in SPEC but I found this when I was working on my loops to memset pass). -- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-17 15:44:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18529
[Bug c/18314] Abnormal behavior in optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 15:46 --- So this is invalid so closing. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18314
[Bug target/18528] miscompilation of inline assembler with -fweb
-- What|Removed |Added Component|c |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18528
[Bug tree-optimization/18374] [meta-bug] Argument and return value marshalling at tree level
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-17 15:53:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18374
[Bug tree-optimization/18507] block_defs_stack varrray should not be GC'ed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 16:00 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01325.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18507
[Bug libstdc++/18530] New: Warning about shadowed variable in locale_facets.tcc
The current g++ emits a warning when compiling the following code
with -O3 -Wshadow:
#include iostream
int main()
{
std::cout 3.5;
}
~/tmpg++ -v -O3 -Wshadow bug.cc
Reading specs
from /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: /scratch/gcc/configure --quiet
--prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,f95
--with-gmp=/afs/mpa/data/martin/mygmp
Thread model: posix
gcc version 4.0.0 20041117 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1plus -quiet
-v -D_GNU_SOURCE bug.cc -quiet -dumpbase bug.cc -mtune=pentiumpro -auxbase bug
-O3 -Wshadow -version -o /tmp/ccn0H39v.s
ignoring nonexistent directory
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/i686-pc-linux-gnu
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/backward
/usr/local/include
/afs/mpa/data/martin/ugcc/include
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/include
/usr/include
End of search list.
GNU C++ version 4.0.0 20041117 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20041117 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/locale_facets.tcc:
In member function 'void std::__numpunct_cache_CharT::_M_cache(const
std::locale) [with _CharT = char]':
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/locale_facets.tcc:140:
instantiated from 'const std::__numpunct_cache_CharT*
std::__use_cachestd::__numpunct_cache_CharT ::operator()(const
std::locale) const [with _CharT = char]'
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/locale_facets.tcc:1087:
instantiated from '_OutIter std::num_put_CharT,
_OutIter::_M_insert_float(_OutIter, std::ios_base, _CharT, char, _ValueT)
const [with _ValueT = double, _CharT = char, _OutIter =
std::ostreambuf_iteratorchar, std::char_traitschar ]'
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/locale_facets.tcc:1252:
instantiated from '_OutIter std::num_put_CharT, _OutIter::do_put(_OutIter,
std::ios_base, _CharT, double) const [with _CharT = char, _OutIter =
std::ostreambuf_iteratorchar, std::char_traitschar ]'
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/locale_facets.h:2353:
instantiated from '_OutIter std::num_put_CharT, _OutIter::put(_OutIter,
std::ios_base, _CharT, double) const [with _CharT = char, _OutIter =
std::ostreambuf_iteratorchar, std::char_traitschar ]'
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/ostream.tcc:246:
instantiated from 'std::basic_ostream_CharT, _Traits
std::basic_ostream_CharT, _Traits::operator(double) [with _CharT = char,
_Traits = std::char_traitschar]'
bug.cc:4: instantiated from here
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/locale_facets.tcc:208:
warning: declaration of '__ct' shadows a member of 'this'
as -V -Qy -o /tmp/ccRZRUA5.o /tmp/ccn0H39v.s
GNU assembler version 2.14 (i686-pc-linux-gnu) using BFD version 2.14 20030612
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.0.0/collect2
--eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/crtbegin.o
-L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0
-L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/../../..
/tmp/ccRZRUA5.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s
-lgcc /afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.0.0/crtend.o
/usr/lib/crtn.o
This is of course not a real bug, but it would still be good if the variable
could be renamed.
--
Summary: Warning about shadowed variable in locale_facets.tcc
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
CC: gcc-bugs at gcc dot gnu dot org
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=18530
[Bug libstdc++/18530] Warning about shadowed variable in locale_facets.tcc
--- Additional Comments From martin at mpa-garching dot mpg dot de 2004-11-17 16:14 --- The warning is only displayed at -O3. Lower optimization levels don't trigger it. -- What|Removed |Added Keywords||diagnostic Known to fail||4.0.0 Known to work||3.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
[Bug fortran/18525] [gfortran] ICE on valid code in gfc_get_symbol_decl()
--- Additional Comments From martin at mpa-garching dot mpg dot de 2004-11-17 16:18 --- Thanks, I have updated the title and keywords now. -- What|Removed |Added Keywords||ice-on-valid-code Summary|[gfortran] ICE on invalid(?)|[gfortran] ICE on valid code |code in |in gfc_get_symbol_decl() |gfc_get_symbol_decl() | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18525
[Bug target/18531] New: Rationalize Altivec logical ops
Altivec patterns are defined at all integer vector modes for GCC named patterns, but not for combiner patterns (e.g., vandc). The patterns probably should use comparison_operator, %q output template, and MD file macro for multiple integer vector modes. -- Summary: Rationalize Altivec logical ops Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: *-*-* GCC host triplet: *-*-* GCC target triplet: powerpc-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18531
[Bug target/18531] Rationalize Altivec logical ops
-- What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-17 16:37:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18531
[Bug libstdc++/18530] Warning about shadowed variable in locale_facets.tcc
--- Additional Comments From pcarlini at suse dot de 2004-11-17 16:44 --- Hi. Frankly, I believe the warning is bogus, and is actually a compiler bug: there is no member of 'this' named __ct, AFAICS. Also the fact that appears only at -O3 (not at -O2, f.i.) seems very suspect... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Additional Comments From gustavo dot boiko at kdemail dot net 2004-11-17 16:59 --- any news on this problem? I've seen some problems like this one in OpenOffice.org cvs HEAD compilation with gcc-3.4.3 because of some inlined class methods at the cppu and the xmlscript modules. -- What|Removed |Added CC||gustavo dot boiko at kdemail ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug libstdc++/18530] Bogus warning about shadowed variable in locale_facets.tcc
--- Additional Comments From martin at mpa-garching dot mpg dot de 2004-11-17 17:00 --- Hi Paolo, I didn't even look that closely, sorry. If the warning is bogus, there is indeed a compiler bug; I have upgraded the severity back to normal and updated the title. -- What|Removed |Added Severity|minor |normal Summary|Warning about shadowed |Bogus warning about shadowed |variable in |variable in |locale_facets.tcc |locale_facets.tcc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
[Bug fortran/18526] fortran testsuite broken
-- What|Removed |Added CC|hjl at lucon dot org| AssignedTo|unassigned at gcc dot gnu |hjl at lucon dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18526
[Bug target/18531] Rationalize Altivec logical ops
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 17:27 --- Note vandc was already done (and approved): http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01328.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18531
[Bug c++/18530] Bogus warning about shadowed variable in locale_facets.tcc
-- What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18530
[Bug tree-optimization/18374] [meta-bug] Argument and return value marshalling at tree level
Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 Here is a bug which says the oposite should be done (as arguments are already done): PR 15484. Unless I misunderstand; C's promotion/evaluation semantics need not be literally applied, but must only yield equivalent results to as if they were. Thereby providing opportunities to the compiler to avoid the otherwise needless promotion of expression/argument precision if it's known that their use in an alternate form will not affect a resulting utilized variable or control flow state. Thereby enabling the compiler to avoid the promotion of arguments to functions, and correspondingly only require their promotion within functions if required. If an ABI specifies that this may not be done, then that's that; but if it's allowed, or not specified, the compiler should be enabled to perform this type of global optimization, I would think. (although GCC may not presently takes full advantage of this potential today.)
[Bug middle-end/16266] [4.0 regression] gcc.dg/c99-intconst-1.c compilation is very slow
--- Additional Comments From fjahanian at apple dot com 2004-11-17 18:02 --- Following patch has broken many dejagnu tests on apple-ppc-darwing with -mcpu=G5. http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gccr1=1.581r2=1.582 FAIL: gcc.c-torture/execute/20041011-1.c compilation, -O1 FAIL: gcc.c-torture/execute/20041011-1.c compilation, -O2 FAIL: gcc.c-torture/execute/950612-1.c compilation, -O1 FAIL: gcc.c-torture/execute/950612-1.c compilation, -O2 FAIL: gcc.c-torture/execute/950612-1.c compilation, -Os FAIL: gcc.c-torture/execute/ashldi-1.c compilation, -O1 FAIL: gcc.c-torture/execute/ashrdi-1.c compilation, -O1 FAIL: gcc.c-torture/execute/ashrdi-1.c compilation, -O2 FAIL: gcc.c-torture/execute/ashrdi-1.c compilation, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/ashrdi-1.c compilation, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/ashrdi-1.c compilation, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/ashrdi-1.c compilation, -O3 -g FAIL: gcc.c-torture/execute/ashrdi-1.c compilation, -Os FAIL: gcc.c-torture/execute/lshrdi-1.c compilation, -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16266
[Bug middle-end/16266] [4.0 regression] gcc.dg/c99-intconst-1.c compilation is very slow
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 18:13 --- I assume that this is a latenet bug exposed by my patch, see http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01110.html for a patch from Dale which might solve this. -- What|Removed |Added CC||fjahanian at apple dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16266
[Bug middle-end/16266] [4.0 regression] gcc.dg/c99-intconst-1.c compilation is very slow
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 18:16 --- In fact I just tested that patch and fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16266
[Bug bootstrap/18532] New: libgcc.mk isn't parallel build safe for multilib
With multilib, libgcc.mk has crtendS.o: stmp-dirs $(MAKE) GCC_FOR_TARGET=$(GCC_FOR_TARGET) \ AR_FOR_TARGET=$(AR_FOR_TARGET) \ AR_CREATE_FOR_TARGET=$(AR_CREATE_FOR_TARGET) \ AR_EXTRACT_FOR_TARGET=$(AR_EXTRACT_FOR_TARGET) \ AR_FLAGS_FOR_TARGET=$(AR_FLAGS_FOR_TARGET) \ CC=$(CC) CFLAGS=$(CFLAGS) \ BUILD_PREFIX=$(BUILD_PREFIX) \ BUILD_PREFIX_1=$(BUILD_PREFIX_1) \ LANGUAGES=$(LANGUAGES) \ LIBGCC2_CFLAGS=$(LIBGCC2_CFLAGS) \ MULTILIB_CFLAGS= T= crtendS.o 32/crtendS.o: stmp-dirs $(MAKE) GCC_FOR_TARGET=$(GCC_FOR_TARGET) \ AR_FOR_TARGET=$(AR_FOR_TARGET) \ AR_CREATE_FOR_TARGET=$(AR_CREATE_FOR_TARGET) \ AR_EXTRACT_FOR_TARGET=$(AR_EXTRACT_FOR_TARGET) \ AR_FLAGS_FOR_TARGET=$(AR_FLAGS_FOR_TARGET) \ CC=$(CC) CFLAGS=$(CFLAGS) \ BUILD_PREFIX=$(BUILD_PREFIX) \ BUILD_PREFIX_1=$(BUILD_PREFIX_1) \ LANGUAGES=$(LANGUAGES) \ LIBGCC2_CFLAGS=$(LIBGCC2_CFLAGS) -m32 \ MULTILIB_CFLAGS= -m32 T=32/ 32/crtendS.o crtbeginT.o: stmp-dirs $(MAKE) GCC_FOR_TARGET=$(GCC_FOR_TARGET) \ AR_FOR_TARGET=$(AR_FOR_TARGET) \ AR_CREATE_FOR_TARGET=$(AR_CREATE_FOR_TARGET) \ AR_EXTRACT_FOR_TARGET=$(AR_EXTRACT_FOR_TARGET) \ AR_FLAGS_FOR_TARGET=$(AR_FLAGS_FOR_TARGET) \ CC=$(CC) CFLAGS=$(CFLAGS) \ BUILD_PREFIX=$(BUILD_PREFIX) \ BUILD_PREFIX_1=$(BUILD_PREFIX_1) \ LANGUAGES=$(LANGUAGES) \ LIBGCC2_CFLAGS=$(LIBGCC2_CFLAGS) \ MULTILIB_CFLAGS= T= crtbeginT.o 32/crtbeginT.o: stmp-dirs $(MAKE) GCC_FOR_TARGET=$(GCC_FOR_TARGET) \ AR_FOR_TARGET=$(AR_FOR_TARGET) \ AR_CREATE_FOR_TARGET=$(AR_CREATE_FOR_TARGET) \ AR_EXTRACT_FOR_TARGET=$(AR_EXTRACT_FOR_TARGET) \ AR_FLAGS_FOR_TARGET=$(AR_FLAGS_FOR_TARGET) \ CC=$(CC) CFLAGS=$(CFLAGS) \ BUILD_PREFIX=$(BUILD_PREFIX) \ BUILD_PREFIX_1=$(BUILD_PREFIX_1) \ LANGUAGES=$(LANGUAGES) \ LIBGCC2_CFLAGS=$(LIBGCC2_CFLAGS) -m32 \ MULTILIB_CFLAGS= -m32 T=32/ 32/crtbeginT.o all: stmp-dirs ./libgcc.a ./libgcov.a ./libgcc_eh.a ./libgcc_s.so 32/libgcc.a 32/libgcov.a 32/libgcc_eh.a 32/libgcc_s_32.so crtbegin.o 32/crtbegin.o crtend.o 32/crtend.o crtbeginS.o 32/crtbeginS.o crtendS.o 32/crtendS.o crtbeginT.o 32/crtbeginT.o When we do make -j N on a SMP machine, we may get make GCC_FOR_TARGET= ./xgcc -B./ -B/usr/gcc-4.0/x86_64-unknown-linux-gnu/bin/ -isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/sys-include -L/export/build/gnu/gcc/build-x86_64-linux/gcc/../ld \ AR_FOR_TARGET=ar \ AR_CREATE_FOR_TARGET=ar rc \ AR_EXTRACT_FOR_TARGET=ar x \ AR_FLAGS_FOR_TARGET= \ CC=stage1/xgcc -Bstage1/ -B/usr/gcc-4.0/x86_64-unknown-linux-gnu/bin/ CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror \ BUILD_PREFIX= \ BUILD_PREFIX_1=loser- \ LANGUAGES=c gcov gcov-dump c++ java objc \ LIBGCC2_CFLAGS=-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 -m32 \ MULTILIB_CFLAGS= -m32 T=32/ 32/crtbegin.o make GCC_FOR_TARGET= ./xgcc -B./ -B/usr/gcc-4.0/x86_64-unknown-linux-gnu/bin/ -isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/sys-include -L/export/build/gnu/gcc/build-x86_64-linux/gcc/../ld \ AR_FOR_TARGET=ar \ AR_CREATE_FOR_TARGET=ar rc \ AR_EXTRACT_FOR_TARGET=ar x \ AR_FLAGS_FOR_TARGET= \ CC=stage1/xgcc -Bstage1/ -B/usr/gcc-4.0/x86_64-unknown-linux-gnu/bin/ CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror \ BUILD_PREFIX= \ BUILD_PREFIX_1=loser- \ LANGUAGES=c gcov gcov-dump c++ java objc \ LIBGCC2_CFLAGS=-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 -m32 \ MULTILIB_CFLAGS= -m32 T=32/ 32/crtend.o make[6]: Entering directory `/export/build/gnu/gcc/build-x86_64-linux/gcc' make[6]: Entering directory `/export/build/gnu/gcc/build-x86_64-linux/gcc' echo | ./xgcc -B./ -B/usr/gcc-4.0/x86_64-unknown-linux-gnu/bin/ -isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/sys-include -L/export/build/gnu/gcc/build-x86_64-linux/gcc/../ld -E -dM - | \ sed -n 's/^#define
[Bug bootstrap/18533] New: EXTRA_MULTILIB_PARTS are used to build libgcc_s.so for multilib
For multilib, EXTRA_MULTILIB_PARTS are used to build libgcc_s.so. I don't think it should be there at all. -- Summary: EXTRA_MULTILIB_PARTS are used to build libgcc_s.so for multilib Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18533
[Bug tree-optimization/18307] merge_pointed_to_info called incorrectly
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-17 21:07 --- Subject: Bug 18307 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-17 21:07:08 Modified files: gcc: ChangeLog tree-ssa-alias.c Log message: PR tree-optimization/18307 * tree-ssa-alias.c (merge_pointed_to_info): ICE if 'dest' and 'orig' are the same node. (collect_points_to_info_r): Do not call merge_pointed_to_info when the PHI argument is identical to the LHS. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6377r2=2.6378 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-alias.c.diff?cvsroot=gccr1=2.53r2=2.54 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18307
[Bug tree-optimization/18307] merge_pointed_to_info called incorrectly
--- Additional Comments From dnovillo at gcc dot gnu dot org 2004-11-17 21:11 --- Fix: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01414.html. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18307
[Bug c++/18534] New: cout operator not in right order
Running on a SuSe 9.1 pro x86_64 machine.
Reading specs from /usr/lib64/gcc/x86_64-suse-linux/3.4.3/specs
Configured with: ./configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man
--enable-languages=c,c++,--disable-checking --libdir=/usr/lib64 --enable-libgcj
--with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib64 --with-system-zlib
--enable-shared --enable-__cxa_atexit x86_64-suse-linux : (reconfigured)
./configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++
--disable-checking --libdir=/usr/lib64 --with-gxx-include-dir=/usr/include/g++
--with-slibdir=/lib64 --with-system-zlib --enable-shared --enable-__cxa_atexit
x86_64-suse-linux
Thread model: posix
gcc version 3.4.3
I dont know if this really is a bug, but i thought you might want to know
I made a class that acts like a buffer, or actually is one. It has a get()
function that increments a pointer to the current item, making it point to the
next item in the buffer. When i do cout bufferclass.get()
bufferclass.get() endl, it wont print it in the right order! (from left to
right).
For instance, i put 2 char's in it ('a', 'b'). Next i do the cout
bufferclass.get() bufferclass.get() endl, and it will print ba.
When i do it in 2 steps, it will print it correct, so its not that my buffer is
screwed. Here is the code for the main:
int main()
{
Chunkchar bla(128);
bla.add('a');
bla.add('b');
cout bla.get() bla.get() endl; // Here is the error
return 0;
}
The output:
[EMAIL PROTECTED]:~/Documents ./bla
ba
Here is the Chunk class. As you can see i also put in a operator[], and it does
work. So bla[0] will return 'a' and bla[1] will return 'b'.
#include cstdlib
#include memory
templateclass T
class Chunk
{
public:
Chunk() { data = current = avail = limit = 0; }
~Chunk();
explicit Chunk(const std::size_t);
bool add(const T);
T get();
T operator[](const std::size_t i) { return data[i]; }
private:
void alloc(const std::size_t);
void dealloc();
std::allocatorT mem;
T* data;
T* current;
T* avail;
T* limit;
};
templateclass T
ChunkT::~Chunk()
{
dealloc();
}
templateclass T
ChunkT::Chunk(const std::size_t s)
{
alloc(s);
}
templateclass T
void ChunkT::alloc(const std::size_t s)
{
data = mem.allocate(s);
current = avail = data;
limit = data + s;
};
templateclass T
void ChunkT::dealloc()
{
if (data)
{
T* iter = avail;
while (iter != avail)
{
mem.destroy(--iter);
}
mem.deallocate(data, limit - data);
}
data = current = avail = limit = 0;
}
templateclass T
bool ChunkT::add(const T t)
{
if (avail == limit)
return false;
mem.construct(avail++, t);
return true;
}
templateclass T
T ChunkT::get()
{
T ret = *current;
current++;
return ret;
}
--
Summary: cout operator not in right order
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: truegrit at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18534
[Bug tree-optimization/17635] [4.0 regression] ICE in verify_ssa: type mismatch
--- Additional Comments From dpatel at apple dot com 2004-11-17 22:13 --- Subject: Re: [4.0 regression] ICE in verify_ssa: type mismatch On Nov 13, 2004, at 5:55 AM, reichelt at gcc dot gnu dot org wrote: --- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-13 13:54 --- Devang, your patch http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg00591.html is responsible for the new ICE. I've fixed this one. But it seems, I am not out of wood yet. - Devang -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17635
[Bug fortran/18526] fortran testsuite broken
--- Additional Comments From hjl at lucon dot org 2004-11-17 22:22 --- *** This bug has been marked as a duplicate of 17466 *** -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18526
[Bug other/17466] Testsuites in gcc override LD_LIBRARY_PATH
--- Additional Comments From hjl at lucon dot org 2004-11-17 22:22 --- *** Bug 18526 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||Thomas dot Koenig at online ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17466
[Bug other/17464] The newly built gcc shared libraries aren't used for bootstap and check
-- Bug 17464 depends on bug 18526, which changed state. Bug 18526 Summary: fortran testsuite broken http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18526 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
[Bug c++/18534] cout operator not in right order
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-17 22:26 --- No this is undefined code. the order of calling a in a() + a() also undefined by the same rule. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18534
[Bug target/17735] [4.0 Regression] make stops with initializer for integer value is too complicated while building an avr-cross compiler
--- Additional Comments From pbrook at gcc dot gnu dot org 2004-11-18 00:21 --- Patch Here. http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01437.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17735
[Bug bootstrap/18532] libgcc.mk isn't parallel build safe for multilib
-- What|Removed |Added BugsThisDependsOn||18533 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18532
[Bug bootstrap/18533] EXTRA_MULTILIB_PARTS are used to build libgcc_s.so for multilib
-- What|Removed |Added OtherBugsDependingO||18532 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18533
[Bug rtl-optimization/16088] [4.0 Regression] Generates wrong code
--- Additional Comments From lucier at math dot purdue dot edu 2004-11-18 01:13 --- Maybe this bug should be closed for lack of specificity. The problem is the following: gcc-4.0 miscompiles C code generated by the Scheme-C compiler Gambit-C (http://www.iro.umontreal.ca/~gambit). I have not been able to debug the problem (all the various version of gdb I tried have not been helpful). In the meantime, two code generation bugs have been fixed (one in the past few days), and several still remain. So the specific information (such as it is) in this bug report is no longer accurate. It is still a fact that gcc-4.0 miscompiles code generated by Gambit-C (and examples of this are easy to find, e.g., the compiler itself aborts in many cases)---perhaps this should be a placeholder bug report for this general problem? I don't know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16088
[Bug rtl-optimization/16088] [4.0 Regression] Generates wrong code
--- Additional Comments From giovannibajo at libero dot it 2004-11-18 01:26 --- OK closing this as invalid then. It would be great if you could reduce it to something attachable. A big preprocessed source code which segfaults is already a starting point, for instance. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16088
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From dpatel at apple dot com 2004-11-18 01:27 --- Bigger issue is : if-convert COND_EXPR is not vectorized and do_jump() does not aborts(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18308
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From dpatel at apple dot com 2004-11-18 01:28 --- I meant, Bigger issue is : if-convert COND_EXPR is not vectorized and do_jump() does not handle it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18308
[Bug middle-end/18535] New: fix_irreducible_loops could be improved
If get_loop_exit_edges would return a VEC (edges) instead of a malloced array,
we could improve the
else stament of when we get the edges to be just an assigment of the SUCCS so
we don't have an extra
setting loop in this case.
The code in quesiton:
if (bb-loop_father-header == bb)
edges = get_loop_exit_edges (bb-loop_father, n_edges);
else
{
n_edges = EDGE_COUNT (bb-succs);
edges = xmalloc (n_edges * sizeof (edge));
FOR_EACH_EDGE (e, ei, bb-succs)
edges[ei.index] = e;
}
(we do not write to edges after this).
See how we just set the edges array to the edge.
--
Summary: fix_irreducible_loops could be improved
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: enhancement
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18535
[Bug tree-optimization/18536] New: ICE: in emit_move_insn, at expr.c:2590 with -ftree-vectorize -msse2
/tmp/gcc4/libexec/gcc/i686-pc-linux-gnu/4.0.0/cc1 -quiet test.c -quiet -dumpbase
test.c -msse2 -auxbase test -O -ftree-vectorize -o test.s -version
GNU C version 4.0.0 20041117 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 2004117 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
test.c: In function 'foo':
test.c:4: internal compiler error: in emit_move_insn, at expr.c:2590
Configured with: ../configure --prefix=/tmp/gcc4 --enable-shared
--enable-languages=c --disable-nls --disable-libmudflap
void foo(a, b)
short a;
short * b;
{
while (++a 4) *b++ = 0;
}
--
Summary: ICE: in emit_move_insn, at expr.c:2590 with -ftree-
vectorize -msse2
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: commie1 at gmx dot net
CC: gcc-bugs at gcc dot gnu dot org
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=18536
[Bug rtl-optimization/17950] Over Aggressive Use of Data Cache Touch Instructions During FDO
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-11-18 01:32 --- Hmmm... looks like a couple things (maybe more) come in to play here. First, value-profile code doesn't seem to merge prefetches (among other things). That is, it should be pretty easy (crude?) to track the last prefetch and not prefetch addresses that look close. Doing so seems to help this test case quite a bit (96 prefetches down to 24), but probably not enough. as it seems that the loop unroller comes through afterwards and does its damage too. Might need to teach the unroller about prefetch a bit too?? -- What|Removed |Added CC||jgrimm2 at us dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17950
[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...
--- Additional Comments From giovannibajo at libero dot it 2004-11-18 01:44 --- Mark, I guess this is the same problem of PR 18327. Will your fix take care of both, or should I look into PR 18327? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
[Bug tree-optimization/18536] ICE: in emit_move_insn, at expr.c:2590 with -ftree-vectorize -msse2
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-18
01:52 ---
Confirmed, the problem I think is the same as the PPC64 problem in PR 18403
but I did not check the
patch which will fix that one for sure.
Breakpoint 1, fancy_abort (file=0x81fcb4
/Users/pinskia/src/apple-ppc-branch/gcc/gcc/expr.c,
line=2485, function=0x81fe9c emit_move_insn) at
/Users/pinskia/src/apple-ppc-branch/gcc/gcc/
diagnostic.c:586
586 internal_error (in %s, at %s:%d, function, trim_filename (file),
line);
(gdb) up
#1 0x00337a2c in emit_move_insn (x=0x4178d7d0, y=0x417b1c48) at
/Users/pinskia/src/apple-
ppc-branch/gcc/gcc/expr.c:2485
2485 (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode));
(gdb) l
2480 enum machine_mode mode = GET_MODE (x);
2481 rtx y_cst = NULL_RTX;
2482 rtx last_insn, set;
2483
2484 gcc_assert (mode != BLKmode
2485 (GET_MODE (y) == mode || GET_MODE (y) == VOIDmode));
2486
2487 if (CONSTANT_P (y))
2488{
2489 if (optimize
(gdb) p debug_rtx(x)
(reg:SI 161 [ iters.6 ])
$1 = void
(gdb) p debug_rtx(y)
(subreg/s/u:HI (reg:SI 163 [ niters.1 ]) 2)
--
What|Removed |Added
CC||dorit at il dot ibm dot com
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2004-11-18 01:52:04
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18536
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From dpatel at apple dot com 2004-11-18 02:26
---
After I update tree-level if-conversion to force gimple operands appropriately,
rewrite_out_of_ssa() is
converting following ...
bar()
{
_Bool _ifc_.3;
_Bool _ifc_.2;
_Bool D.1339;
_Bool D.1336;
_Bool D.1337;
_Bool D.1338;
_Bool _ifc_.1;
unsigned int ivtmp.0;
int k;
int j;
int i;
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
k_21 = j_6 != 0 ? 2 : 0;
k_5 = j_6 == 0 ? k_21 : 2;
if (k_5 != 0) goto L5; else goto L6;
# SUCC: 1 [46.5%] (true,exec) 2 [53.5%] (false,exec)
# BLOCK 1
# PRED: 0 [46.5%] (true,exec)
L5:;
# .GLOBAL_VAR_10 = V_MAY_DEF .GLOBAL_VAR_9;
foo () [tail call];
# SUCC: 2 [100.0%] (fallthru,exec)
# BLOCK 2
# PRED: 0 [53.5%] (false,exec) 1 [100.0%] (fallthru,exec)
L6:;
return;
# SUCC: EXIT [100.0%]
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-18 02:29 --- So someone removed too much from do_jump in the first place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18308
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-18 02:31 --- And that would mean it was caused by: * dojump.c (do_jump) COND_EXPR, EQ_EXPR, NE_EXPR, TRUTH_ANDIF_EXPR, TRUTH_ORIF_EXPR, COMPOUND_EXPR: Abort on gimplified cases. -- What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18308
[Bug fortran/18537] New: no warning about tabs with std=f95 option
Tabs in source code are not standard Fortran but are accepted by many compilers. Gfortran should at least warn about the use of tabs when invoked with the -std=f95 option. The Compaq Visual Fortran and Intel compilers do so. -- Summary: no warning about tabs with std=f95 option Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18537
[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274
--- Additional Comments From dpatel at apple dot com 2004-11-18 02:33
---
Subject: Re: ICE in do_jump, at dojump.c:274
Andrew,
You can try following to fix tree level if-conversion. I have not
tested it completely yet.
-
Devang
Index: tree-if-conv.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-if-conv.c,v
retrieving revision 2.19
diff -Idpatel.pbxuser -c -3 -p -r2.19 tree-if-conv.c
*** tree-if-conv.c 16 Nov 2004 20:02:48 - 2.19
--- tree-if-conv.c 18 Nov 2004 02:32:03 -
*** add_to_dst_predicate_list (struct loop *
*** 639,645
new_cond = unshare_expr (cond);
else
{
! tree tmp_stmt;
/* new_cond == prev_cond AND cond */
tree tmp = build (TRUTH_AND_EXPR, boolean_type_node,
unshare_expr (prev_cond), cond);
--- 639,655
new_cond = unshare_expr (cond);
else
{
! tree tmp_stmt = NULL_TREE;
! tree tmp_stmts1 = NULL_TREE;
! tree tmp_stmts2 = NULL_TREE;
! prev_cond = force_gimple_operand (unshare_expr (prev_cond),
tmp_stmts1, true, NULL);
! if (tmp_stmts1)
! bsi_insert_before (bsi, tmp_stmts1, BSI_SAME_STMT);
!
! cond = force_gimple_operand (unshare_expr (cond), tmp_stmts2,
true, NULL);
! if (tmp_stmts2)
! bsi_insert_before (bsi, tmp_stmts2, BSI_SAME_STMT);
!
/* new_cond == prev_cond AND cond */
tree tmp = build (TRUTH_AND_EXPR, boolean_type_node,
unshare_expr (prev_cond), cond);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18308
[Bug fortran/18537] no warning about tabs with std=f95 option
-- What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18537
[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...
--- Additional Comments From mark at codesourcery dot com 2004-11-18 07:59 --- Subject: Re: [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer... giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2004-11-18 01:44 --- Mark, I guess this is the same problem of PR 18327. Will your fix take care of both, or should I look into PR 18327? I haven't fixed either bug yet, so go for it! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
