[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16 08:41 --- I am going to reopen them and remove the avr/h8300 from PR18542. You can easily check that by testing if reverting the patch from comment #2 helps. Please read what I wrote in comment #10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
[Bug target/18563] ICE: output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16 08:44 --- WTH are you permantently closing this PR? This PR is addressing the h8300 and one of the m68k-maintainers (Bernardo) had explicitly requested me to split the h8300-case from the m68k. Upset, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18563
[Bug c++/19030] New: ice on tree check
# g++ libkmailprivate_la_all_cpp.ii -c (...errors...) KMail::MaildirJob' ./kmail/kmfoldermaildir.h:10: error: 'struct KMail::MaildirJob' has a previous declaration as 'struct KMail::MaildirJob' ./kmail/maildirjob.h:41: internal compiler error: tree check: expected class 'declaration', have 'exceptional' (error_mark) in pushtag, at cp/name-lookup.c:4672 # gcc -v Reading specs from /usr/lib/gcc/pentium3-pld-linux/4.0.0/specs Configured with: ../configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --infodir=/usr/share/info--mandir=/usr/share/man --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++,f95,objc,ada,java --enable-c99 --enable-long-long --enable-multilib --enable-nls --with-gnu-as --with-gnu-ld --with-system-zlib --with-slibdir=/lib --without-x --enable-cmath pentium3-pld-linux Thread model: posix gcc version 4.0.0 20041212 (experimental) (PLD Linux) -- Summary: ice on tree check Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at pld-linux dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: pentium3-pld-linux GCC host triplet: pentium3-pld-linux GCC target triplet: pentium3-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug c++/19030] ice on tree check
--- Additional Comments From pluto at pld-linux dot org 2004-12-16 09:09 --- Created an attachment (id=7753) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7753action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug rtl-optimization/19001] [3.4/4.0 Regression] Loops with power of two step and variable bounds not unrolled
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-12-16 09:18 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01203.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19001
[Bug target/19005] [3.4 regression] Error: bad register name `%sil'
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 09:31 --- Subject: Bug 19005 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2004-12-16 09:31:18 Modified files: gcc: ChangeLog gcc/config/i386: i386.md Log message: PR target/19005 * config/i386/i386.md (swaphi_1): Swap with swaphi_2, allow with optimize_size. (swapqi_1): Rename from swapqi. Enable only for no partial reg stall and optimize_size. (swapqi_2): New. (swaphi_1, swaphi_2, swapqi_1): Add athlon_decode. (swapsi, swaphi_1, swaphi_2, swapqi_1, swapdi): Remove modrm override. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1039r2=1.16114.2.1040 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.404.2.27r2=1.404.2.28 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19005
[Bug target/19005] [3.4 regression] Error: bad register name `%sil'
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-16 09:37 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19005
[Bug target/19028] [3.4/4.0 Regression] ICE in libjava
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 09:43 --- Subject: Bug 19028 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-16 09:42:51 Modified files: gcc: ChangeLog gcc/config/i386: i386.md Log message: PR target/19028 * config/i386/i386.md (sse compare splitter): Test for SF and DFmode explicitly instead of using VALID_SSE_REG_MODE. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6852r2=2.6853 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gccr1=1.580r2=1.581 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19028
[Bug target/19028] [3.4/4.0 Regression] ICE in libjava
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-16 09:54 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19028
[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 10:23 --- Subject: Bug 18882 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-16 10:23:32 Modified files: gcc: ChangeLog function.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: complex1.C Log message: PR middle-end/18882 * function.c (assign_stack_local_1): Use BITS_PER_UNIT alignment when passed -2 as 'align'. (put_var_into_stack): Use 'bool' as the type for the three local predicates. Adjust calls to put_reg_into_stack. When passed a CONCAT, instruct put_reg_into_stack to use a consecutive stack slot for the second part. (put_reg_into_stack): Remove 'promoted_mode' parameter, add 'consecutive_p' parameter. Turn the three predicates into 'bool' parameters. Retrieve the register mode from 'reg'. When consecutive_p is true, instruct assign_stack_local_1 to use BITS_PER_UNIT alignment. (put_addressof_into_stack): Use 'bool' as the type for the two local predicates. Adjust call to put_reg_into_stack. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.743r2=2.2326.2.744 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.483.4.22r2=1.483.4.23 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.327r2=1.3389.2.328 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/complex1.C.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug c++/19018] [3.3 Regression] virtual memory exhausted
--- Additional Comments From david at starks-browning dot com 2004-12-16 10:30 --- True, but I don't believe the patch for PR16273 is applicable to gcc-3.3. In fact, I am unable to reproduce the fault in gcc-3.3 using the 10,000-line test case that was attached to PR16273. Therefore, my guess is that the smaller test case (attachment id 6664) was refined against gcc-3.4 and led to the patch that fixed the symptom in gcc-3.4. I don't know how much of that effort could be applied to gcc-3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19018
[Bug c++/18905] [4.0 Regression] Strange error: subscripted value is neither array nor pointer
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-16 11:00 --- 2004-12-16 Nathan Sidwell [EMAIL PROTECTED] PR c++/18905 * cp-tree.h (integral_constant_value): Declare. * call.c (null_ptr_cst_p): Use integral_constant_value, not decl_constant_value. (convert_like_real): Likewise. * class.c (check_bitfield_decl): Likewise. * cvt.c (ocp_convert): Likewise. (convert): Remove unnecessary decl_constant_value call. * decl.c (compute_array_index_type): Use integral_constant_value, not decl_constant_value. (build_enumerator): Likewise. * decl2.c (grokfield): Likewise. * init.c (decl_constant_value): Simplify. (integral_constant_value): New. * pt.c (fold_decl_constant_value): Use integral_constant_value, remove subsequent check. (tsubst): Use integral_constant_value, not decl_constant_value. (tsubst_copy, unify): Likewise. * typeck.c (decay_conversion): Likewise. (build_compound_expr): Remove unnecessary decl_constant_value calls. (build_static_cast_1, build_reinterpret_cast_1): (convert_for_assignment): Remove comment about not calling decl_constant_value. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18905
[Bug c++/18905] [4.0 Regression] Strange error: subscripted value is neither array nor pointer
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 11:04 --- Subject: Bug 18905 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-16 11:04:09 Modified files: gcc/cp : call.c class.c cp-tree.h cvt.c decl.c decl2.c init.c pt.c typeck.c ChangeLog gcc/testsuite/g++.dg/opt: static3.C gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/template: init4.C Log message: cp: PR c++/18905 * cp-tree.h (integral_constant_value): Declare. * call.c (null_ptr_cst_p): Use integral_constant_value, not decl_constant_value. (convert_like_real): Likewise. * class.c (check_bitfield_decl): Likewise. * cvt.c (ocp_convert): Likewise. (convert): Remove unnecessary decl_constant_value call. * decl.c (compute_array_index_type): Use integral_constant_value, not decl_constant_value. (build_enumerator): Likewise. * decl2.c (grokfield): Likewise. * init.c (decl_constant_value): Simplify. (integral_constant_value): New. * pt.c (fold_decl_constant_value): Use integral_constant_value, remove subsequent check. (tsubst): Use integral_constant_value, not decl_constant_value. (tsubst_copy, unify): Likewise. * typeck.c (decay_conversion): Likewise. (build_compound_expr): Remove unnecessary decl_constant_value calls. (build_static_cast_1, build_reinterpret_cast_1): (convert_for_assignment): Remove comment about not calling decl_constant_value. testsuite: PR c++/18905 * g++.dg/template/init4.C: New. * g++.dg/opt/static3.C: Enable optimizer. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gccr1=1.522r2=1.523 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/class.c.diff?cvsroot=gccr1=1.694r2=1.695 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1080r2=1.1081 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cvt.c.diff?cvsroot=gccr1=1.173r2=1.174 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gccr1=1.1341r2=1.1342 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gccr1=1.760r2=1.761 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gccr1=1.405r2=1.406 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.958r2=1.959 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gccr1=1.604r2=1.605 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4538r2=1.4539 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/static3.C.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4768r2=1.4769 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/init4.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18905
[Bug libfortran/19032] New: modulo generates wrong result
$ cat mod-neg.f90 integer :: a,b a = 2 b = -1 print *,modulo(2,-1) print *,modulo(a,b) end $ gfortran mod-neg.f90 ./a.out 0 -1 $ gfortran -v Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs Configured with: ../gcc-4.0-20041212/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 : (reconfigured) ../gcc-4.0-20041212/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 --disable-shared Thread model: posix gcc version 4.0.0 20041212 (experimental) It's a bit strange that the first result is correct, and the second one isn't. -- Summary: modulo generates wrong result Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran 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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
[Bug c++/14075] (foo) accepted as char[] initializer
--- Additional Comments From nathan at gcc dot gnu dot org 2004-12-16 11:41 --- what a silly restriction ... -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14075
[Bug fortran/18998] Gfortran produces wrong output (c/f to g77)
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16 11:47 --- The code runs correctly on IA-64. $ gfortran fft2.for $ ./a.out 0.00 0.00 0.00 0.00 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 4.00 0.00 0.00 0.00 STOP 0 $ gfortran -O3 fft2.for $ ./a.out 0.00 0.00 0.00 0.00 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 4.00 0.00 0.00 0.00 STOP 0 For comparison: $ ifort fft2.for $ ./a.out 0.000E+00 0.000E+00 0.000E+00 0.000E+00 4.00 0.000E+00 0.000E+00 0.000E+00 0.000E+00 0.000E+00 0.000E+00 0.000E+00 4.00 0.000E+00 0.000E+00 0.000E+00 $ gfortran -v Reading specs from /home/zfkts/lib/gcc/ia64-unknown-linux-gnu/4.0.0/specs Configured with: ../gcc-4.0-20041212/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 : (reconfigured) ../gcc-4.0-20041212/configure --prefix=/home/zfkts --enable-languages=c,c++,f95 --disable-shared Thread model: posix gcc version 4.0.0 20041212 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18998
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From joseph at codesourcery dot com 2004-12-16 12:33 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) On Thu, 16 Dec 2004, zack at codesourcery dot com wrote: Because of the ABI implications, I consider it completely unacceptable Which ABI implications? (a) It isn't explicitly stated that different UCNs designating the same character are equivalent to each other (and to that character) in identifiers, but I don't think there's any real doubt that they are meant to be equivalent. (b) There is no normalisation, but I'm confident that the answer from WG14 if this is queried would be that the standard is correct and by design it normatively references ISO 10646 (not Unicode) which doesn't include the normalisation definitions of UAX 15 and implementation of the standard is not meant to involve large external tables. If there are cases of ambiguity a -Wnfc option (default on) to warn for identifiers not in NFC (or indeed -Wnfkc, default on, for identifiers not in NFKC) would draw users' attention to doubtful identifiers. (TR 10176 expressly notes the problems of ambiguity of appearance of entirely different characters even without combining characters, says that language standards need not provide for normalisation if they allow combining characters, and excludes most combining characters where precombined characters are available for the specific purpose of avoiding alternate representations of identifiers.) (c) Though we could do what we want with extended characters (as opposed to UCNs) in source files in phase 1, it seems safest to err on the side of rejecting all extended characters that wouldn't be accepted as UCNs, rather than e.g. applying NFC, to avoid giving identifiers with such characters a meaning which might then need to be preserved in future. (d) There are genuine ABI issues with how extended characters are represented in object files, but I think those need to be resolved by selecting between UTF-8 and mangling (default UTF-8) based on target configurations rather than on the capabilities of the assembler and linker in use, and by getting an explicit statement about encoding put in the ELF specification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug middle-end/18776] [4.0 Regression] Libgfortran doesn't build again
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-16 12:55 --- The error has changed a bit: /home/eric/cvs/gcc/libgfortran/generated/_exp_c4.f90: In function 'specific__exp_c4': /home/eric/cvs/gcc/libgfortran/generated/_exp_c4.f90:28: internal compiler error: in schedule_insns, at sched-rgn.c:2551 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. but it is still related to liveness info and complex values. -- What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2004-12-16 12:55:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18776
[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results
--- Additional Comments From jbeulich at novell dot com 2004-12-16 12:59 --- This happens when the ABI is (was) imprecise. Earlier versions did not special case long double complex, but the current version does. Hence I have a patch ready that partly reverses the original change (actually, implements the original behavior for this type in a form slightly closer matching the ABI definition); expecting to submit this later today or tomorrow (currently building/testing). As to the same(?) problem observed with float complex: I doubt the mentioned patch causes this, since behavior for that type wasn't modified by it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17603
[Bug c/14765] [3.3 Regression] ice-on-invalid-code, ICE while compiling ({}) expression
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-16 12:54 --- Bootstrapped and regtested on 3.3 branch. Gaby, is it ok to commit the patch in comment #4 to the 3.3 branch? Do we need the testcase? -- What|Removed |Added CC||gdr at gcc dot gnu dot org Known to fail|3.4.0 3.3.4 tree-ssa 3.2.3 |3.4.0 3.3.5 3.3 3.2.3 3.1 |3.2.2 3.1 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14765
[Bug target/19009] Loading of FP constants into FP reg via SSE reg
--- Additional Comments From uros at kss-loka dot si 2004-12-16 13:50 --- -finline-functions is needed to trigger the bug with -O2. The attached testcase should be compiled with '-O2 -march=pentium4 -mfpmath=387 -ffast-math -D__NO_MATH_INLINES -finline-functions' to get: ... pxor%xmm0, %xmm0 movsd %xmm0, -16(%ebp) fldl-16(%ebp) fcomip %st(1), %st je .L23 fld %st(0) ... and: grep xmm zero.s pxor%xmm0, %xmm0 movsd %xmm0, -16(%ebp) movsd %xmm0, -16(%ebp) movsd %xmm0, -16(%ebp) movsd %xmm0, -16(%ebp) movsd %xmm0, 8(%edx) movsd %xmm0, (%edx) where movsds are followed by: fldl-16(%ebp) BTW: #include math.h can be removed from testcase to avoid -D__NO_MATH_INLINES. Ther result will be the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19009
[Bug c/19033] New: Passing array as a function parameter in C99 style fails
The following code fails to compile:
pl-1.c:
void print(int res, int K, double a[K][K])
{
}
int inverse(int K,double in[K][K],double out[K][K])
{
return 0;
}
int main(void)
{
int K;
double a[K][K];
double b[K][K];
print(inverse(K, a, b),K,b);
return 0;
}
[EMAIL PROTECTED] ~]$ gcc -v -save-temps -O2 -std=gnu99 pl-1.c
Reading specs from /usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --prefix=/usr --sysconfdir=/etc --
localstatedir=/var --enable-shared --with-gnu-as --with-gnu-ld --enable-
threads --enable-__cxa_atexit --enable-initfini-array --disable-nls --with-
system-zlib --enable-java-awt=gtk,xlib
Thread model: posix
gcc version 3.4.3
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1 -E -quiet -v pl-1.c -
mtune=pentiumpro -std=gnu99 -O2 -o pl-1.i
ignoring nonexistent directory /usr/lib/gcc/i686-pc-linux-
gnu/3.4.3/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include
/usr/include
End of search list.
/usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1 -fpreprocessed pl-1.i -quiet -
dumpbase pl-1.c -mtune=pentiumpro -auxbase pl-1 -O2 -std=gnu99 -version -o pl-
1.s
GNU C version 3.4.3 (i686-pc-linux-gnu)
compiled by GNU C version 3.4.3.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64552
pl-1.c: In function `print':
pl-1.c:6: error: prior parameter's size depends on 'K'
pl-1.c:6: error: prior parameter's size depends on 'K'
pl-1.c:6: error: prior parameter's size depends on 'K'
pl-1.c:6: error: prior parameter's size depends on 'K'
[EMAIL PROTECTED] ~]$
It compiles OK with -O0 and -O1.
--
Summary: Passing array as a function parameter in C99 style fails
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzo at lib dot msu dot ru
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19033
[Bug middle-end/18590] [3.3/3.4 regression] ICE in add_insn_before, at emit-rtl.c:3599
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 13:59 --- Subject: Bug 18590 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2004-12-16 13:59:03 Modified files: gcc: ChangeLog function.c Log message: PR middle-end/18590 * function.c (fixup_var_refs_insns_with_hash): Do not invoke fixup_var_refs_insn on insns marked as deleted. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1040r2=1.16114.2.1041 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.389.2.16r2=1.389.2.17 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18590
[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 14:07 --- Subject: Bug 18882 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2004-12-16 14:04:54 Modified files: gcc: ChangeLog function.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/other: complex1.C Log message: PR middle-end/18882 * function.c (assign_stack_local_1): Use BITS_PER_UNIT alignment when passed -2 as 'align'. (put_var_into_stack): Adjust calls to put_reg_into_stack. When passed a CONCAT, instruct put_reg_into_stack to use a consecutive stack slot for the second part. (put_reg_into_stack): Remove 'promoted_mode' parameter, add 'consecutive_p' parameter. Retrieve the register mode from 'reg'. When consecutive_p is true, instruct assign_stack_local_1 to use BITS_PER_UNIT alignment. (put_addressof_into_stack): Adjust call to put_reg_into_stack. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.16114.2.1041r2=1.16114.2.1042 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.389.2.17r2=1.389.2.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.2261.2.389r2=1.2261.2.390 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/other/complex1.C.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=NONEr2=1.1.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug c++/19034] New: internal compiler error: in cp_tree_equal, at cp/tree.c:1633
Following command causes an ICE /home/jttoivon/usr/bin/g++ -v -save-temps poista.cpp This used to work with 3.3.3 compiler. Here's the dump. Reading specs from /home/jttoivon/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/specs Configured with: /home/jttoivon/gcc-3.4.3/configure --prefix=/home/jttoivon/usr Thread model: posix gcc version 3.4.3 /home/jttoivon/usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1plus -E -quiet -v -D_GNU_SOURCE poista.cpp -mtune=pentiumpro -o poista.ii ignoring nonexistent directory /home/jttoivon/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /home/jttoivon/boost_1_31_0 /home/jttoivon/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3 /home/jttoivon/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/i686-pc-linux-gnu /home/jttoivon/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/../../../../include/c++/3.4.3/backward /usr/local/include /home/jttoivon/usr/include /home/jttoivon/usr/lib/gcc/i686-pc-linux-gnu/3.4.3/include /usr/include End of search list. /home/jttoivon/usr/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1plus -fpreprocessed poista.ii -quiet -dumpbase poista.cpp -mtune=pentiumpro -auxbase poista -version -o poista.s GNU C++ version 3.4.3 (i686-pc-linux-gnu) compiled by GNU C version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 In file included from poista.cpp:1: meta.hpp:188: internal compiler error: in cp_tree_equal, at cp/tree.c:1633 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in cp_tree_equal, at cp/tree.c:1633 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jttoivon at cc dot helsinki dot fi CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19034
[Bug middle-end/18882] [3.3/3.4 Regression] wrong results with complex long double
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-16 14:09 --- See http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01119.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|3.4.4 |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18882
[Bug libfortran/18985] opening unit 6 messes up print
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-16 14:10 --- Done thusly :-) BTW the directions discussions on comp.lang.fortran turn are fun. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18985
[Bug c++/19034] internal compiler error: in cp_tree_equal, at cp/tree.c:1633
--- Additional Comments From jttoivon at cc dot helsinki dot fi 2004-12-16 14:12 --- Created an attachment (id=7757) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7757action=view) source code that doesn't compile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19034
[Bug java/18091] Valgrind errors building libjava
--- Additional Comments From aph at gcc dot gnu dot org 2004-12-16 14:29 --- comment -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18091
[Bug target/19009] Loading of FP constants into FP reg via SSE reg
--- Additional Comments From uros at kss-loka dot si 2004-12-16 14:35
---
Another candidate for TARGET_SSE_MATH cleanup...
(insn 21 20 22 0 (set (reg:CCFP 17 flags)
(compare:CCFP (reg/v:DF 60 [ mod ])
(reg:DF 70))) 24 {*cmpfp_i_sse} (nil)
(nil))
--
What|Removed |Added
Last reconfirmed|-00-00 00:00:00 |2004-12-16 14:35:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19009
[Bug libfortran/19032] modulo generates wrong result for divisor -1
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-16 14:41 --- I checked gfortran against the examples in the standard, and we seem to only get the case modulo (..., -1) wrong (result should be 0, we print -1) -- What|Removed |Added Summary|modulo generates wrong |modulo generates wrong |result |result for divisor -1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
[Bug libfortran/19032] modulo generates wrong result for divisor -1
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-16 14:42 --- (In reply to comment #1) The second result is correct, the first wrong. It's the other way round, as might be obvious from comment #2 Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
[Bug middle-end/18493] [3.4 Regression] gcc doesn't like switch blocks without case/default labels
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 14:43 --- Subject: Bug 18493 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-12-16 14:42:50 Modified files: gcc: ChangeLog c-typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: switch-4.c Log message: PR middle-end/18493 * c-typeck.c (c_finish_case): Rechain statements if we didn't encounter any case labels or a default. * gcc.dg/switch-4.c: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.744r2=2.2326.2.745 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.272.2.10r2=1.272.2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.328r2=1.3389.2.329 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/switch-4.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.22.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18493
[Bug middle-end/16417] [4.0 Regression] crappy code (gcc.c-torture/compile/20020210-1.c) in arguments causes ICE
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2004-12-16 14:40 --- Subject: Re: [4.0 Regression] crappy code (gcc.c-tortur cft: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01174.html -- What|Removed |Added Status|ASSIGNED|WAITING On hppa-unknown-linux-gnu and hpp2.0w-hp-hpux11.11, this leads to a bootstrap comparison failure: Bootstrap comparison failure! ./alias.o differs ./bb-reorder.o differs ./bt-load.o differs ./builtins.o differs ./c-aux-info.o differs ./c-common.o differs ./c-cppbuiltin.o differs ./c-decl.o differs ... On hppa64-hp-hpux11.11, we don't get as far: /test/gnu/gcc-3.3/objdir/gcc/gfortran -B/test/gnu/gcc-3.3/objdir/gcc/ -B/opt/gnu 64/gcc/gcc-4.0.0/hppa64-hp-hpux11.11/bin/ -B/opt/gnu64/gcc/gcc-4.0.0/hppa64-hp-h pux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4.0.0/hppa64-hp-hpux11.11/include -isy stem /opt/gnu64/gcc/gcc-4.0.0/hppa64-hp-hpux11.11/sys-include -g -O2 -Wall -fno- repack-arrays -fno-underscoring -c ../../../gcc/libgfortran/intrinsics/selected_ int_kind.f90 -fPIC -DPIC -o .libs/selected_int_kind.o ../../../gcc/libgfortran/intrinsics/selected_int_kind.f90: In function 'selected _int_kind': ../../../gcc/libgfortran/intrinsics/selected_int_kind.f90:22: internal compiler error: Segmentation fault I can try look at these problems tonight. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16417
[Bug libfortran/19032] modulo generates wrong result
--- Additional Comments From tobi at gcc dot gnu dot org 2004-12-16 14:30 --- The second result is correct, the first wrong. The difference results from the fact that the first statement is evaluated by gfortran's constant folding pass, whereas the second is evaluated in generated code. In other words, the code generation for modulo is wrong. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-16 14:30:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
[Bug java/18931] jar - .so optimization problem
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Component|middle-end |java Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-16 14:59:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18931
[Bug java/18931] jar - .so optimization problem
--- Additional Comments From aph at gcc dot gnu dot org 2004-12-16 15:00 --- Bumping priority because this is possibly a front end bug that breaks many programs/ -- What|Removed |Added Severity|normal |critical Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18931
[Bug java/19036] New: readObject memory consumption
I'm using the 4.0 Windows port downloaded from http://www.thisiscool.com/gcc_mingw.htm. It has been very useful for me, since the libjcj in 4.0 is way more complete than the one on the current releases. And I'm also using SWT and other things that works out of the box on this special release. But now I'm facing this issue, wich I don't know if it happens on the current snapshots. Really, I've tried a bit to build the snapshots, and failed. I lack the experience to do it. So, here it is. The problem is the big memory consumption that the readObject part of the testcase shows (Just see it on the Task Manager). This is a very much simplified situation than the one I'm working on, but is enough to show the problem. Any ideas? -- Summary: readObject memory consumption Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nkuzminski at gmail dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19036
[Bug java/19036] readObject memory consumption
--- Additional Comments From nkuzminski at gmail dot com 2004-12-16 15:05 --- Created an attachment (id=7759) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7759action=view) Testcase showin big memory consumption on the readObject part -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19036
[Bug c++/19004] [3.4/4.0 regression] ICE in uses_template_parms at cp/pt.c:4860
-- What|Removed |Added AssignedTo|lerdsuwa at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19004
[Bug c++/19034] [3.4/4.0 Regression] internal compiler error: in cp_tree_equal, at cp/tree.c:1633
--- Additional Comments From belyshev at lubercy dot com 2004-12-16 15:08
---
// reduced testcase
template bool C struct B
{
};
templatetypename S int foo();
templatetypename S int foo1();
templatetypename T struct bar : public B (sizeof(fooT()) == 1)
{
};
templatetypename T struct bar1 : public B (sizeof(foo1T()) == 1)
{
};
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code
Known to fail||3.4.4 4.0.0
Known to work||3.3.5
Last reconfirmed|-00-00 00:00:00 |2004-12-16 15:08:27
date||
Summary|internal compiler error: in |[3.4/4.0 Regression]
|cp_tree_equal, at |internal compiler error: in
|cp/tree.c:1633 |cp_tree_equal, at
||cp/tree.c:1633
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19034
[Bug ada/19037] New: constant renaming creates new constant
Look at the following example: with System; use System; with Ada.Text_Io; use Ada.Text_IO; procedure foo is bar : constant integer := 1; foobar : integer renames bar; begin if foo'Address = foobar'Address then Put_Line (OK); end if; end foo; The normal output of this program would be OK, but in fact the test fails. Another example: package foo is bar : constant integer := 1; foobar : integer renames bar; end foo; $ gcc -c foo.ads Two symbols are created: $ nm foo.o D foo__bar 0001 C foo_E 0004 D foo__foobar Futhermore I checked and both symbols reserve space (there 4 bytes). $ objdump -t foo.o [...] g O .data 0004 foo__bar 0004 g O .data 0004 foo__foobar Nevertheless both get the right value: $ readelf -x 2 foo.o Hex dump of section '.data': 0x 0001 0001 If I declare a variable instead of a constant, then we get the normal behaviour (ie only 1 symbol and 1 space for it): package Foo is Bar : Integer := 1; FooBar : Integer renames Bar; end Foo; $ gcc -c foo.ads $ nm foo.o D foo__bar 0001 C foo_E -- Summary: constant renaming creates new constant Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jc at apinc dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19037
[Bug c++/19034] [3.4/4.0 Regression] internal compiler error: in cp_tree_equal, at cp/tree.c:1633
--- Additional Comments From belyshev at lubercy dot com 2004-12-16 15:20 --- : Search converges between 2003-06-18-trunk (#268) and 2003-06-19-trunk (#269). -- What|Removed |Added Known to fail|3.4.4 4.0.0 |3.4.0 3.4.1 3.4.2 3.4.3 ||3.4.4 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19034
[Bug c/14765] [3.3 Regression] ice-on-invalid-code, ICE while compiling ({}) expression
--- Additional Comments From gdr at integrable-solutions dot net
2004-12-16 14:05 ---
Subject: Re: [3.3 Regression] ice-on-invalid-code, ICE while compiling ({})
expression
reichelt at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Bootstrapped and regtested on 3.3 branch.
|
| Gaby, is it ok to commit the patch in comment #4 to the 3.3 branch?
| Do we need the testcase?
This bug seems to have an interesting history...
yes, if you can pleas apply it.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14765
[Bug rtl-optimization/19038] New: Loop header copying
Loop header copying would allow some loops to be transformed from two or more basic blocks into a single basic block, allowing better scheduling of the instructions in the loop. This would help SPEC CPU2000 sixtrack benchmark, for example. -- Summary: Loop header copying Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P2 Component: rtl-optimization 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: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results
--- Additional Comments From jbeulich at novell dot com 2004-12-16 15:46 --- Patch for the x86-64 long double complex part submitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17603
[Bug fortran/18977] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16 15:59 --- I reran the tests with the 20041114 snapshot at -O1, and the segfault did indeed go away, so this is a regression. Quite likely, this is a IA-64 target problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug middle-end/18493] [3.4 Regression] gcc doesn't like switch blocks without case/default labels
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:25 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18493
[Bug libgcj/19036] readObject memory consumption
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:27 --- Note This version is almost 3 months old. -- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19036
[Bug c/19031] [4.0 Regression] #pragma weak handling changes in 4.0.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:31 --- Well the following patch changed it: 2004-11-29 Daniel Jacobowitz [EMAIL PROTECTED] PR c/7544 * Makefile.in (c-lang.o): Update dependencies. * c-lang.c: Include c-pragma.h. (finish_file): Call maybe_apply_pending_pragma_weaks. * c-pragma.c (maybe_apply_pending_pragma_weaks): New function. * c-pragma.h (maybe_apply_pending_pragma_weaks): New prototype. -- What|Removed |Added CC||jsm28 at gcc dot gnu dot org Keywords||wrong-code Summary|#pragma weak handling |[4.0 Regression] #pragma |changes in 4.0.0|weak handling changes in ||4.0.0 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19031
[Bug target/17603] [4.0 Regression] cpowf and cpowl give wrong results
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 16:33 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01223.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17603
[Bug c/19033] Passing array as a function parameter in C99 style fails
--- Additional Comments From bangerth at dealii dot org 2004-12-16 16:50 --- This is a duplicate of PR 15114. It is fixed on mainline, but the audit trail of that PR states that it is not going to be fixed for 3.4.x. W. *** This bug has been marked as a duplicate of 15114 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19033
[Bug middle-end/15114] [3.4 regression] -funit-at-a-time causes compilation of functions with variable length arrays to fail
--- Additional Comments From bangerth at dealii dot org 2004-12-16 16:50 --- *** Bug 19033 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||bonzo at lib dot msu dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15114
[Bug c++/19030] [4.0 Regression] ice on tree check
--- Additional Comments From bangerth at dealii dot org 2004-12-16 17:01 --- Created an attachment (id=7762) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7762action=view) Slightly smaller testcase Attached is a slightly smaller testcase (down to 183,000 lines or so). The bug may actually be relatively easy to fix even without a small testcase: I would imagine that there is only a check for error_mark_node missing somewhere, and finding this place should be easy. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19030
[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2004-12-16 17:08 ---
The attached patch makes us for -O3 -funroll-loops -ffast-math produce in .vars
float foobar() ()
{
bb 0:
return a.array[3] * b.array[3] + a.array[2] * b.array[2] + a.array[0] *
b.array[0] + a.array[1] * b.array[1];
}
though the assembly is as good as before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18754
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-16 18:07 --- Someone had a bad day: case ARRAY_TYPE: case VECTOR_TYPE: /* We're already checked the component type (TREE_TYPE), so just check the index type. */ return type_contains_placeholder_p (TYPE_DOMAIN (type)); But a VECTOR_TYPE doesn't have a TYPE_DOMAIN, so we ICE. This is the cause of the gcc.dg/i386-3dnow-[12].c failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug preprocessor/19040] New: #elif token1 token2 doesn't produce a diagnostic
GCC emits diagnostics for following...
$ cat a.c
int foo()
{
#ifdef FOO
return 1;
#elif BAR FOO
return 0;
#endif
}
$ cc a.c -c
a.c:6:11: error: missing binary operator before token FOO
$
However, it does not emit diagnostics for following ...
$ cat a.c
#define FOO 1
int foo()
{
#ifdef FOO
return 1;
#elif BAR FOO
return 0;
#endif
}
--
Summary: #elif token1 token2 doesn't produce a diagnostic
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040
[Bug target/19039] [4.0 Regression] another SSE optimization ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 18:19 --- This is a dup of bug 17767. *** This bug has been marked as a duplicate of 17767 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Keywords||ice-on-valid-code Resolution||DUPLICATE Summary|another SSE optimization ICE|[4.0 Regression] another SSE ||optimization ICE Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19039
[Bug c++/18829] Error signale on an unexisting line
--- Additional Comments From federicotomassetti at yahoo dot it 2004-12-16 18:31 --- No I provided info needed to analyze this bug -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18829
[Bug c/19039] New: another SSE optimization ICE
Attached testcase ICEs GCC:
[opel:/Volumes/sandbox/stuart] hasting2% gcc.fsf.debug.obj/gcc/xgcc -B
gcc.fsf.debug.obj/gcc -O1 -
msse2 -S m4.i
m4.i: In function 'rrr':
m4.i:36: error: unrecognizable insn:
(insn 283 210 211 10 (set (reg:V16QI 22 xmm1)
(const_int 1 [0x1])) -1 (nil)
(nil))
m4.i:36: internal compiler error: in extract_insn, at recog.c:2020
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
---
Here is the testcase:
---
typedef unsigned long ulong;
typedef long long __v2di __attribute__ ((vector_size (16)));
typedef char __v16qi __attribute__ ((vector_size (16)));
typedef struct
{
void *v1;
ulong kk;
ulong ss;
}bbbccc;
long rrr(const bbbccc *od, ulong lc, ulong rc, ulong br, ulong kw)
{
long i, j, x, y, kx = kw, ky, p1 = (kx)/2, r1 = (ky)/2, kk = od-kk, q1 =
lc - p1, sts = p1, lml = od-
ss - rc, g1, *pg1, i1, s1, j1;
char *out = (char*) od-v1;
__v2di h1;
for( i = 0; i kk; i++ )
{
j1 = i + r1;
if( i = kk - (long) br )
j1 = ( kk-1) + r1 - (long) br;
s1 = j1 - i1;
for(; y s1; y++ )
{
for( x = q1; x sts; x++ )
;
}
out[j] = g1;
for( ; j = lml - 16; j += 16 )
{
h1 = (__v2di)__builtin_ia32_pcmpeqb128 ((__v16qi)h1, (__v16qi)h1);
for( y = 0; y s1; y++ )
for( x = 0; x (long) kw; x++ )
;
__builtin_ia32_storedqu ((char *)pg1, (__v16qi)h1);
}
}
}
--
Summary: another SSE optimization ICE
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-apple-darwin
GCC host triplet: i686-apple-darwin
GCC target triplet: i686-apple-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19039
[Bug c/19041] New: -fvisibility=hidden causes bad codegen for common symbols
Compile the following file with -fvisibility=hidden
int foo;
void bar(void) { foo = 0; }
You will find that the assembler rejects the .s file that the compiler creates,
giving the error:
/var/tmp//cclfEVh7.s:16:non-relocatable subtraction expression, _foo minus
L001$pb
/var/tmp//cclfEVh7.s:16:symbol: _foo can't be undefined in a subtraction
expression
The assembler is right to complain. The compiler generates these lines:
addis r2,r31,ha16(_foo-L001$pb)
la r2,lo16(_foo-L001$pb)(r2)
This is incorrect. Common symbols must be treated as undefined symbols, so
they must be addressed
indirectly through non-lazy pointers. Without -fvisibility=hidden, the
compiler gets this right.
--
Summary: -fvisibility=hidden causes bad codegen for common
symbols
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.6.0
GCC host triplet: powerpc-apple-darwin7.6.0
GCC target triplet: powerpc-apple-darwin7.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19041
[Bug target/19041] -fvisibility=hidden causes bad codegen for common symbols
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 19:10 --- Mine, I posted a patch last week, I will find it again and add the link to the bug here. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Component|c |target Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2004-12-16 19:10:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19041
[Bug target/19041] [4.0 Regression] -fvisibility=hidden causes bad codegen for common symbols
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 19:12 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00814.html, this is a regression from before Mark implemented his speed up. There is also a better testcase which does not use the option but attributes instead. -- What|Removed |Added Keywords||patch Summary|-fvisibility=hidden causes |[4.0 Regression] - |bad codegen for common |fvisibility=hidden causes |symbols |bad codegen for common ||symbols Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19041
[Bug other/18508] [3.4/4.0 Regression] basename: too few arguments when building without bootstrap
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 19:14 --- Subject: Bug 18508 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-16 19:14:29 Modified files: gcc: ChangeLog gcc/config : t-libunwind-elf t-slibgcc-darwin t-slibgcc-elf-ver t-slibgcc-sld gcc/config/alpha: t-osf4 gcc/config/arm : t-netbsd gcc/config/i386: t-nwld gcc/config/mips: t-slibgcc-irix gcc/config/pa : t-hpux-shlib gcc/config/sh : t-linux Log message: 2004-12-14 H.J. Lu [EMAIL PROTECTED] PR other/18508 * config/alpha/t-osf4 (SHLIB_LINK): Use `.backup' as the suffix to back up the existing shared library. * config/arm/t-netbsd (SHLIB_LINK): Likewise. * config/mips/t-slibgcc-irix (SHLIB_LINK): Likewise. * config/pa/t-hpux-shlib (SHLIB_LINK): Likewise. * config/sh/t-linux (SHLIB_LINK): Likewise. * config/t-libunwind-elf (SHLIBUNWIND_LINK): Likewise. * config/t-slibgcc-darwin (SHLIB_LINK): Likewise. * config/t-slibgcc-elf-ver (SHLIB_LINK): Likewise. * config/t-slibgcc-sld (SHLIB_LINK): Likewise. * config/i386/t-nwld (SHLIB_LINK): Don't use the temporary file. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6857r2=2.6858 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-libunwind-elf.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-darwin.diff?cvsroot=gccr1=1.7r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-elf-ver.diff?cvsroot=gccr1=1.9r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/t-slibgcc-sld.diff?cvsroot=gccr1=1.9r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/t-osf4.diff?cvsroot=gccr1=1.8r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arm/t-netbsd.diff?cvsroot=gccr1=1.8r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/t-nwld.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/mips/t-slibgcc-irix.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/t-hpux-shlib.diff?cvsroot=gccr1=1.3r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/sh/t-linux.diff?cvsroot=gccr1=1.15r2=1.16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18508
[Bug other/18508] [3.4/4.0 Regression] basename: too few arguments when building without bootstrap
--- Additional Comments From hjl at lucon dot org 2004-12-16 19:17 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18508
[Bug tree-optimization/19042] Complex types are not SRA all the time.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 19:32 --- Note we end up with: D.770 = COMPLEX_EXPR D.768 - 4.0e+0, 0.0; ca1$imag = IMAGPART_EXPR D.770; ca1$real = REALPART_EXPR D.770; in .t66.final_cleanup -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug tree-optimization/19042] New: Complex types are not SRA all the time.
I decided to look into sixtrack and noticed this. I will add a small testcase after I reduce the problem. -- Summary: Complex types are not SRA all the time. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: minor 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 GCC target triplet: powerpc-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug c++/19043] New: -fpermissive gives bad loop initializations
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
int main() {
//int i;
for(int i = 1; i 0; ++i);
for(i = 2; i 4; ++i) {
for(int j = 3; j 5; ++j) {
cout i j endl;
}
}
}
outputs
3 3
4 4
initializing i outside of the first for loop gives
2 3
2 4
3 3
3 4
--
Summary: -fpermissive gives bad loop initializations
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: japple at freeshell dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: Red Hat 3.4.3-10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19043
[Bug target/18997] [4.0 Regression] Segmentation Violation in pthread_getspecific
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-16 19:56 --- Subject: Bug 18997 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-12-16 19:56:12 Modified files: gcc: ChangeLog gcc/config/i386: cygwin.h libstdc++-v3 : ChangeLog libstdc++-v3/config/os/newlib: os_defines.h Log message: gcc PR target/18997 * config/i386/cygwin.h (GTHREAD_USE_WEAK): Define to 0. libstdc++-v3 PR target/18997 * config/os/newlib/os_defines.h (_GLIBCXX_GTHREAD_USE_WEAK): Define to 0 for __CYGWIN__. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.6859r2=2.6860 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/cygwin.h.diff?cvsroot=gccr1=1.85r2=1.86 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gccr1=1.2813r2=1.2814 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/config/os/newlib/os_defines.h.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18997
[Bug tree-optimization/18707] [4.0 Regression] Performance regression at -O2 with gzip
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-12-16 20:04 --- See http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01232.html -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18707
[Bug tree-optimization/19042] Complex types are not SRA all the time.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:30 --- Here is the reduced testcase (fortran): COMMON TA(6,6) COMPLEX*16 CA1,CA2,CLAM2 CA2=DCMPLX(F2,ZERO) CA2=SQRT(CA2) CLAM2=(EGWG2+CA2)/TWO DO 40 I=1,4 TA(I,3)=DREAL(CLAM2) 40 CONTINUE RETURN END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug tree-optimization/19042] Complex types are not SRA all the time.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:40 --- Here it is further reduced: COMMON TA(6,6) COMPLEX*16 CA2,CLAM2 CLAM2=DCMPLX(a,2.0) DO 40 I=1,4 TA(I,3)=DREAL(CLAM2) 40 CONTINUE RETURN END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug tree-optimization/19042] Complex types are not SRA all the time.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:38 --- Here it is further reduced: COMMON TA(6,6) COMPLEX*16 CA2,CLAM2 CA2=DCMPLX(F2,ZERO) CLAM2=(EGWG2+CA2)/TWO DO 40 I=1,4 TA(I,3)=DREAL(CLAM2) 40 CONTINUE RETURN END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug tree-optimization/19042] Complex types are not SRA all the time.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:49 --- This is most likely a dup of bug 18268. -- What|Removed |Added BugsThisDependsOn||18268 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug target/18997] [4.0 Regression] Segmentation Violation in pthread_getspecific
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 20:49 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18997
[Bug tree-optimization/19042] Complex types are not SRA all the time.
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 21:03 --- And here is a testcase where we don't use an unitialized variable and no loops either: COMMON TA,A COMPLEX*16 CLAM2 CLAM2=DCMPLX(A,2.0) TA=DIMAG(CLAM2) RETURN END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic
--- Additional Comments From dpatel at apple dot com 2004-12-16 21:07 --- Subject: Re: #elif token1 token2 doesn't produce a diagnostic On Dec 16, 2004, at 1:01 PM, bangerth at dealii dot org wrote: That's because it doesn't have to evaluate the #elif condition any more, since it has already taken the #ifdef branch. But that's the point. My reading of C99 standard does not give preprocessor this freedom. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040
[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic
--- Additional Comments From bangerth at dealii dot org 2004-12-16 21:01 --- That's because it doesn't have to evaluate the #elif condition any more, since it has already taken the #ifdef branch. If you change the code to #ifdef BAR return 1; #elif BAR FOO return 0; #endif } it again issues the warning. This almost seems like a sensible approach. W. -- What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040
[Bug c++/19044] New: Alternate asm name for atan ignored when calling __builtin_atan
For atan (and other functions like it), calling __builtin_atan is sometimes
supposed to fall back to the
library version of atan. In the C++ front end, this interacts poorly with
alternate asm names.
Consider the following test case:
#ifdef __cplusplus
extern C
#endif
double atan(double x) __asm(_fancy_atan);
double foo(double x) { return __builtin_atan(x); }
When it's compiled as C, it gives the behavior I expect: foo calls _fancy_atan.
The C++ front end,
however, gets it wrong: we call _atan, ignoring the fact that this function is
supposed to have a different
assembler name.
--
Summary: Alternate asm name for atan ignored when calling
__builtin_atan
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: austern at apple dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.6.0
GCC host triplet: powerpc-apple-darwin7.6.0
GCC target triplet: powerpc-apple-darwin7.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19044
[Bug rtl-optimization/19038] Loop header copying
--- Additional Comments From dje at gcc dot gnu dot org 2004-12-16 21:39 --- The focus of the problem is the inner loop of functio thin6d at line 572. The function consumes 97.5% of the cycles and the inner loop consumes 48.5%. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug fortran/19045] New: ICE in gfc_conv_expr
I think this is different than the existing Fortran failures. If '(ims:,jms:)'is changed to '(ims,jms)' or '(ims:ime,jms:jme)' things work. Test case: SUBROUTINE foo ( dnew , ims, jms, ime, jme) IMPLICIT NONE INTEGER ims, jms, ime, jme REAL , DIMENSION(ims:,jms:) :: dnew INTEGER i i = dnew(10,10) END SUBROUTINE foo The failure: % gfortran -c x.f90 x.f90: In function 'foo': x.f90:1: internal compiler error: in gfc_conv_expr, at fortran/trans-expr.c:1807 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in gfc_conv_expr Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19045
[Bug tree-optimization/18268] structure copy propagation not done
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-16 22:07 --- SRA shouldn't be responsible for this. There should be a generalized block copy propagator. Which would help with copies far larger than you'd ever expect SRA to handle as well. -- What|Removed |Added Severity|normal |enhancement Last reconfirmed|2004-12-07 18:51:32 |2004-12-16 22:07:40 date|| Summary|missed SRA of a block copy |structure copy propagation ||not done http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18268
[Bug target/19046] New: [4.0 Regression] MOVE_RATIO should be tweaked
Take the following C++ code:
class StringMap {
const char empty_str[8];
public:
StringMap() : empty_str() {}
};
StringMap f()
{
StringMap a;
return a;
}
For 3.3.2, we produced (at -O3):
__Z1fv:
LFB6:
li r4,0
stw r4,0(r3)
stw r4,4(r3)
blr
on the mainline we get:
__Z1fv:
LFB5:
mflr r0
LCFI0:
bcl 20,31,L001$pb
L001$pb:
stw r31,-4(r1)
LCFI1:
mflr r31
stw r0,8(r1)
LCFI2:
addis r2,r31,ha16(__ZZN9StringMapC1EvE3C.0-L001$pb)
la r9,lo16(__ZZN9StringMapC1EvE3C.0-L001$pb)(r2)
lwz r10,4(r9)
lwz r9,0(r9)
stw r10,4(r3)
lwz r0,8(r1)
lwz r31,-4(r1)
mtlr r0
stw r9,0(r3)
blr
--
Summary: [4.0 Regression] MOVE_RATIO should be tweaked
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: target
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
GCC target triplet: powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19046
[Bug target/19046] [4.0 Regression] MOVE_RATIO should be tweaked
-- What|Removed |Added Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19046
[Bug libfortran/19032] modulo generates wrong result for divisor -1
--- Additional Comments From Thomas dot Koenig at online dot de 2004-12-16 22:40 --- Reals are also broken: $ cat mod-real.f90 program main real :: a,b a = 2.0 b = -1.0 print *,modulo(a,b) end program main $ gfortran mod-real.f90 $ ./a.out -1.00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19032
[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic
--- Additional Comments From neil at gcc dot gnu dot org 2004-12-16 22:38 --- Not a bug - the standard requires this. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040
[Bug c++/19047] New: Template template argument matching can violate SFINAE
The following program fails to compile:
#include iostream
templatetemplateint class CT, int TA
void operator(CTTA, int);
int main()
{
std::cout Hello, world\n;
}
The error messages given are:
test.cpp: In function `int main()':
test.cpp:8: error: template argument 2 is invalid
--
Summary: Template template argument matching can violate SFINAE
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benh at bwsint dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19047
[Bug preprocessor/19040] #elif token1 token2 doesn't produce a diagnostic
--- Additional Comments From dpatel at apple dot com 2004-12-16 22:54 --- Subject: Re: #elif token1 token2 doesn't produce a diagnostic Neil, Would it be possible to quote standard here? We encountered this while running Plum Hall tests, so I just wanted to make sure. Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19040
[Bug rtl-optimization/19038] Loop header copying
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-16
22:55 ---
The interesting thing is that the front end already does the header
copying when it generates code:
{
int4 D.1164;
D.1164 = nmz;
k = 3;
k.12 = k;
if (k.12 = D.1164)
{
D1500:;
{
...loop body, straight-line code...
__label_000420:;
k.12 = k;
D.1168 = k.12 == D.1164;
k.12 = k;
D.1522 = k.12 + 1;
k = D.1522;
if (D.1168)
{
goto L.51;
}
else
{
}
}
goto D1500;
}
else
{
}
L.51:;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038
[Bug c++/19047] Template template argument matching can violate SFINAE
-- What|Removed |Added GCC build triplet||i486-linux GCC host triplet||i486-linux GCC target triplet||i486-linux Keywords||rejects-valid Known to fail||3.0.4 3.2.3 3.3.4 3.4.3 Known to work||2.95.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19047
[Bug c++/19047] Template template argument matching can violate SFINAE
-- What|Removed |Added Known to work|2.95.4 |2.95.4 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19047
[Bug preprocessor/9449] UCNs not recognized in identifiers (c++/c99)
--- Additional Comments From joseph at codesourcery dot com 2004-12-16 23:04 --- Subject: Re: UCNs not recognized in identifiers (c++/c99) The following example illustrates the problems with lack of normalisation. (I still expect WG14 and WG21 to consider the lack of normalisation to be both the current meaning of the standards and their correct meaning in context, though future revisions might change the exact lists of characters, but this is an appropriate example to present to them and shows why diagnostics would be needed for various cases.) \u05e9\u05bc\u05c1 \u05e9\u05c1\u05bc are valid identifiers in C99 but not C++ while \ufb2c is a valid identifier in C++ but not in C99. In Unicode, the three are canonically equivalent, the first being both NFC and NFD. 05BC HEBREW POINT DAGESH OR MAPIQ (combining class 21) 05C1 HEBREW POINT SHIN DOT (combining class 24) 05E9 HEBREW LETTER SHIN (combining class 0) FB2C HEBREW LETTER SHIN WITH DAGESH AND SHIN DOT (combining class 0) (U+FB2C is excluded from the compositions allowed in NFC, hence the decomposed form being NFC.) So with current C and C++ standards users cannot portably link some pointed Hebrew identifiers between the two languages; it would be advisable for them to avoid such identifiers. Warning for any use of the characters permitted by C++ but not C seems appropriate in the expectation that such characters will cease to be permitted in future, regardless of any other changes there may be. Making the C++ extern C \ufb2c into something else would seem to me to be the road to madness, though we could see how other implementations of the C++ ABI interpret it as regards identifiers with UCNs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9449
[Bug tree-optimization/19042] Complex types are not SRA all the time.
-- What|Removed |Added CC||dje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
[Bug ada/19048] New: Assertion failure on illegal program
The following code will make gcc abort: package foo is A : constant Integer := 1; B : Integer renames A; B : constant Integer := 2; end foo; $ gcc -c foo.ads +===GNAT BUG DETECTED==+ | 3.4.4 20041128 (prerelease) (Debian 3.4.3-3) (i486-pc-linux-gnu) | | Assert_Failure sinfo.adb:1063| | Error detected at foo.ads:5:4| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-3.4 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please note that if A and B aren't constant gcc detects the conflicting declaration and don't abort. So I guess that this bug might be linked to the bug #19037 -- Summary: Assertion failure on illegal program Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jc at apinc dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19048
[Bug c++/19047] [3.3/3.4 Regression] Template template argument matching can violate SFINAE
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16
23:28 ---
Reduced testcase:
templateclass _CharT struct char_traits {};
templatetypename _CharT, typename _Traits = char_traits_CharT
class basic_ostream {};
templateclass _Traits
basic_ostreamchar, _Traits
operator(basic_ostreamchar, _Traits __out, const char* __s);
extern basic_ostreamchar cout;
templatetemplateint class CT, int TA
void operator(CTTA, int);
int main()
{
cout Hello, world\n;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-12-16 23:28:32
date||
Summary|Template template argument |[3.3/3.4 Regression]
|matching can violate SFINAE |Template template argument
||matching can violate SFINAE
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19047
[Bug c++/19047] [3.3/3.4 Regression] Template template argument matching can violate SFINAE
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:28 --- Fixed on the mainline: : Search converges between 2004-11-14-014001-trunk (#634) and 2004-11-14-161001-trunk (#635). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19047
[Bug fortran/19045] ICE in gfc_conv_expr
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:32 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-16 23:32:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19045
[Bug c++/19043] [3.4/3.3 only] -fpermissive gives bad loop initializations
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:41 --- 3.3.2 does not work but the mainline works. -- What|Removed |Added Keywords||wrong-code Known to fail||3.3.2 Known to work||4.0.0 Summary|-fpermissive gives bad loop |[3.4/3.3 only] -fpermissive |initializations |gives bad loop ||initializations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19043
[Bug target/19019] GCC ldouble format incompatibility with XLC long double
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:41 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-12-16 23:41:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19019
[Bug ada/19037] constant renaming creates new constant
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-16 23:48 --- Confirmed, note for the procedure case, we put the const decl on the stack (at least on ppc-darwin). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2004-12-16 23:48:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19037
