[Bug c++/30144] New: Wrong base member lookup in template.
g++ rejects following code.
templateclass T struct B
{
void foo() { }
};
template class T struct D: Bint,BT
{
void bar() { foo(); } // call Bint::foo()
};
int main()
{
Dvoid x;
x.bar();
return 0;
}
---
$ gcc cc.cpp
cc.cpp: In member function 'void DT::bar() [with T = void]':
cc.cpp:14: instantiated from here
cc.cpp:8: error: request for member 'foo' is ambiguous
cc.cpp:3: error: candidates are: void BT::foo() [with T = void]
cc.cpp:3: error: void BT::foo() [with T = int]
--
Summary: Wrong base member lookup in template.
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30144
gcc 3.4.5 bug
Dear Sirs,
I use gcc 3.4.5 and received following incorrect result in the program.
On the gcc site exist report about incorrect behavior of ++ operator but not
this situation. I hope that it will be usefull.
I have developed some stupid code to show the problem:
#include stdio.h
void upcase(char* str) {
size_t len;
len = strlen(str);
while(len-- 0 )
*str++ = toupper(*str);
}
int main(int argc, char** argv) {
char buf[1000];
scanf(%s,buf);
upcase(buf);
printf(\n%s,buf);
}
Compile: gcc -o test.exe -O2 tcode.c
Problem:
Without optimization such chunk of code is working fine, but with O2
optimization,
I have incorrect result due to gcc incremented esi earlier than read data and
as
the result - the first letter is lost.
DISASM -
mov ebx, esi
inc esi
movsx eax, byte ptr [esi]
mov [esp+18h+var_18], eax
calltoupper
mov [ebx], al
DISASM -
Best Regards,
crow16384
[Bug c++/30144] Wrong base member lookup in template.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-11 08:09 --- *** This bug has been marked as a duplicate of 15272 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30144
[Bug c++/15272] lookup, dependent base
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-11 08:09 --- *** Bug 30144 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||s__nakayama at infoseek dot ||jp http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15272
Re: gcc 3.4.5 bug
On Mon, 2006-12-11 at 11:06 +0300, XXX XXX wrote: Dear Sirs, I use gcc 3.4.5 and received following incorrect result in the program. On the gcc site exist report about incorrect behavior of ++ operator but not this situation. I hope that it will be usefull. I have developed some stupid code to show the problem: *str++ = toupper(*str); This is not a bug. Please read: http://gcc.gnu.org/bugs.html#nonbugs_c Increment/decrement operator (++/--) not working as expected - a problem with many variations. The following expressions have unpredictable results: x[i]=++i foo(i,++i) i*(++i) /* special case with foo==operator* */ std::cout i ++i /* foo(foo(std::cout,i),++i) */ since the i without increment can be evaluated before or after ++i. The C and C++ standards have the notion of sequence points. Everything that happens between two sequence points happens in an unspecified order, but it has to happen after the first and before the second sequence point. The end of a statement and a function call are examples for sequence points, whereas assignments and the comma between function arguments are not. Modifying a value twice between two sequence points as shown in the following examples is even worse: i=++i foo(++i,++i) (++i)*(++i) /* special case with foo==operator* */ std::cout ++i ++i /* foo(foo(std::cout,++i),++i) */ This leads to undefined behavior (i.e. the compiler can do anything). --Pinski
[Bug c++/30139] overflow warning for unevaluated part of expression
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-11 08:20 --- I think the C front-end is incorrect in not warning, though someone has to look into the standard to be sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30139
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #30 from jv244 at cam dot ac dot uk 2006-12-11 09:51 --- (In reply to comment #29) simple testcase for the segfault: SUBROUTINE S(unit_number) character(len=100) :: status_string integer :: unit_number,istat status_string=KEEP CLOSE (UNIT=unit_number,IOSTAT=istat,STATUS=TRIM(status_string)) END SUBROUTINE INTEGER :: unit_number unit_number=100 OPEN(unit_number) CALL S(unit_number) END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #31 from burnus at gcc dot gnu dot org 2006-12-11 10:07 ---
gcc version 4.3.0 20061210 (experimental)
simple testcase for the segfault:
I tried it with gfortran 4.3 and 4.2 (today's build) and an older 4.1 build and
neither crashes. valgrind also shows no error.
The original program gives here:
** ** PROGRAM ENDED AT 20061211
110945.641
i.e. it also seems to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #32 from jv244 at cam dot ac dot uk 2006-12-11 11:29 --- (In reply to comment #31) gcc version 4.3.0 20061210 (experimental) simple testcase for the segfault: I tried it with gfortran 4.3 and 4.2 (today's build) and an older 4.1 build and neither crashes. valgrind also shows no error. OK, latest svn and a build from scratch resolved that segfault. Could there be something wrong with the gcc build system ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #33 from jv244 at cam dot ac dot uk 2006-12-11 11:54 --- Running the CP2K regtests now results in: number of FAILED tests 24 (these are just the runs that do not complete, I have not checked that the runs that finish also generate the right numbers. This can be reproduced using the do_regtest script mentioned in the initial description). Just for future reference the current failures are: 1 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-2/H2-vib.inp.out 2 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-2/H2O-meta_res1.inp.out 3 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-2/H2O-meta_res2.inp.out 4 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-2/H2O-meta_res3.inp.out 5 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-gpw-3/H2O-langevin-2.inp.out 6 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/water_1_res_3.inp.out 7 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/H2O-32_SPME_res_4.inp.out 8 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/H2O-32_NPT_res_2.inp.out 9 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/H2O-32_NPT_res_3.inp.out 10 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/H2O-32_NPT_res_4.inp.out 11 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/silicon_cluster_3.inp.out 12 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/silicon_cluster_4.inp.out 13 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/silicon_cluster_5.inp.out 14 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/silicon_cluster_6.inp.out 15 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QS/regtest-ot-1/H2O-OT-ASPC-6.inp.out 16 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QMMM/QS/regtest-3/C4H10-qmmm-gauss-7.inp.out 17 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/wat_freq.inp.out 18 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/wat_freq_norot.inp.out 19 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Fist/regtest/wat_freq_freeze.inp.out 20 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/QMMM/QS/regtest-3/C4H10-qmmm-grid-8.inp.out 21 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/EP/Ar-ep.inp.out 22 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/EP/Ar2.inp.out 23 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/EP/3H2O-ep.inp.out 24 /scratch/vondele/clean/TEST-Linux-x86-64-gfortran-sdbg-2006-12-11T12:27:29+0100/Pimd/h2o_pint.inp.out Some of them seem to be caused by the same issue, but there is a number of distinct problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc and i386
--- Comment #32 from irar at il dot ibm dot com 2006-12-11 12:46 --- I am attaching the bad rs6000.s (generated with vectorization) and good rs6000.s (generated with vectorization and -fno-move-loop-invariants) using revision 110852 (from February 2006). I looked over these a bit, but I wouldn't like to hunt down a bug that had since been solved, so I think I'll switch to looking into more recent snapshots. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug fortran/30145] New: Print/write
-- Summary: Print/write Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pmason at ricardo dot com GCC build triplet: gcc version 4.3.0 20061211 (experimental) GCC host triplet: suse9 (x86_64) GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30145
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc and i386
--- Comment #33 from irar at il dot ibm dot com 2006-12-11 12:57 --- Created an attachment (id=12779) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12779action=view) Bad rs6000.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug fortran/30145] Print/write
--- Comment #1 from pmason at ricardo dot com 2006-12-11 12:58 --- Created an attachment (id=12780) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12780action=view) Fortran 90 testcase for zero-sized array printing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30145
[Bug middle-end/28752] bootstrap comparision fails with -ftree-vectorize -maltivec on ppc and i386
--- Comment #34 from irar at il dot ibm dot com 2006-12-11 13:02 --- Created an attachment (id=12781) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12781action=view) Good rs6000.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
[Bug fortran/30145] Fortran 90: write statement fails to ignore zero-sized array...
--- Comment #2 from pmason at ricardo dot com 2006-12-11 13:05 --- Write statement (fortran90) fails to ignore zero-sized array when bounds on array are variable. Please see zeros.f90 file attached. This was compiled as gfortran zeros.f90 on suse9 (x86_64) box using version 4.3.0 20061211 (experimental). -- pmason at ricardo dot com changed: What|Removed |Added Summary|Print/write |Fortran 90: write statement ||fails to ignore zero-sized ||array... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30145
[Bug libstdc++/30127] std::has_facet returns true for not installed derived facets
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-12-11 13:49 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-11 13:49:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30127
[Bug libstdc++/28265] iconv-related errors while building a cross-compiler for MinGW
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-12-11 13:56 --- Hey Ranjit. It looks like this error is from extc++.h.gch, the precompiled header for libstdc++ that includes std/tr1/ext. From the file libstdc++-v3/include/ext/codecvt_specializations.h: #ifndef _EXT_CODECVT_SPECIALIZATIONS_H #define _EXT_CODECVT_SPECIALIZATIONS_H 1 #include bits/c++config.h #ifdef _GLIBCXX_USE_ICONV #include locale #include iconv.h ... So, I would think this would pick up iconv_t. If not, what include is needed? best,benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28265
[Bug fortran/30146] New: Redefining do-variable in excecution cycle
I think the following program is wrong as one uses a passes a do variable to an intent(inout) (or intent(out) subroutine). However, neither g95, sunf95 nor NAG f95 complain at compile time. Using nagf95 -C=all I get at run time: Actual argument for INTENT(INOUT) dummy argument I is an expression (I get this whether or not I set i in the suboutine.) Am I missing something? From the standard (8.1.6.4.2 The execution cycle): Except for the incrementation of the DO variable that occurs in step (3), the DO variable shall neither be redefined nor become undefined while the DO construct is active. Once could implement this by setting a flag to the do-variable on for the excecution cycle, and removing the flag on exit. Then one could check the result in resolve.c. Or look at gfc_check_do_variable in parse.c. I don't know whether the output should be a warning or an error, but the following program runs 2 4 6 with nagf95, ifort and sunf95, 2 4 6 8 10 with g95 and 2 4 ... 142434 ... with gfortran. program main implicit none integer :: i do i = 1,5,1 call mysub(i) print *, i end do contains subroutine mysub(i) integer,intent(inout) :: i i = i + 1 end subroutine mysub end program main -- Summary: Redefining do-variable in excecution cycle Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
[Bug target/30120] [4.3 Regression] silent miscompilation of argument passing
--- Comment #4 from uros at gcc dot gnu dot org 2006-12-11 14:06 --- Subject: Bug 30120 Author: uros Date: Mon Dec 11 14:06:07 2006 New Revision: 119734 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119734 Log: PR target/30120 Revert: 2006-11-15 Uros Bizjak [EMAIL PROTECTED] * config/i386/i386.opt: New target option -mx87regparm. * config/i386/i386.h (struct ix86_args): Add x87_nregs, x87_regno, float_in_x87: Add new variables. mmx_words, sse_words: Remove. (X87_REGPARM_MAX): Define. * config/i386/i386.c (override_options): Error out for -mx87regparm but no 80387 support. (ix86_attribute_table): Add x87regparm. (ix86_handle_cconv_attribute): Update comments for x87regparm. (ix86_comp_type_attributes): Check for mismatched x87regparm types. (ix86_function_x87regparm): New function. (ix86_function_arg_regno_p): Add X87_REGPARM_MAX 80387 floating point registers. (init_cumulative_args): Initialize x87_nregs and float_in_x87 variables. (function_arg_advance): Process x87_nregs and x87_regno when floating point argument is to be passed in 80387 register. (function_arg): Pass XFmode arguments in 80387 registers for local functions. Pass SFmode and DFmode arguments to local functions in 80387 registers when flag_unsafe_math_optimizations is set. * reg-stack.c (convert_regs_entry): Disable NaN load for stack registers that are used for argument passing. * doc/extend.texi: Document x87regparm function attribute. * doc/invoke.texi: Document -mx87regparm. testsuite/ChangeLog: PR target/30120 * gcc.target/i386/pr30120.c: New test. Revert: 2006-11-15 Uros Bizjak [EMAIL PROTECTED] * gcc.target/i386/x87regparm-1.c: New test. * gcc.target/i386/x87regparm-2.c: New test. * gcc.target/i386/x87regparm-3.c: New test. * gcc.target/i386/x87regparm-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr30120.c Removed: trunk/gcc/testsuite/gcc.target/i386/x87regparm-1.c trunk/gcc/testsuite/gcc.target/i386/x87regparm-2.c trunk/gcc/testsuite/gcc.target/i386/x87regparm-3.c trunk/gcc/testsuite/gcc.target/i386/x87regparm-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h trunk/gcc/config/i386/i386.opt trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/reg-stack.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30120
[Bug c++/24525] g++ fails to warn when converting UDT through double to int
--- Comment #3 from georgeh at rentec dot com 2006-12-11 14:34 --- (In reply to comment #2) Is this what you wished? Yes. -- georgeh at rentec dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24525
[Bug middle-end/30147] New: [regression 4.3] ICE in fold_convert with -O2
Today's gfortran crashes with -c -O2 for the program below. It works with today's 4.2.0 and with -O. I don't see right away whether this is a middle end or middle-end triggered front-end problem. input_cp2k_motion2.f90: In function 'create_neb_section': input_cp2k_motion2.f90:12: internal compiler error: in fold_convert, at fold-const.c:2150 MODULE input_cp2k_motion IMPLICIT NONE interface SUBROUTINE keyword_create(variants) CHARACTER(len=*), DIMENSION(:), INTENT(in) :: variants end subroutine end interface CONTAINS SUBROUTINE create_neb_section() CALL keyword_create(variants=(/K/)) END SUBROUTINE create_neb_section END MODULE input_cp2k_motion -- Summary: [regression 4.3] ICE in fold_convert with -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30147
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #34 from burnus at gcc dot gnu dot org 2006-12-11 15:56 --- CP2k actually gives here an ICE with -O2 (PR 30147) at least when I use ./do_regtest (otherwise I didn't saw it). I did not yet look at why the calculation results are wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #35 from jv244 at cam dot ac dot uk 2006-12-11 16:08 --- (In reply to comment #34) CP2k actually gives here an ICE with -O2 (PR 30147) at least when I use ./do_regtest (otherwise I didn't saw it). I did not yet look at why the calculation results are wrong. yes, I'm currently also getting this gfortran -c -O3 -ftree-vectorize -ffast-math -march=opteron input_cp2k_motion.f90 input_cp2k_motion.f90: In function ‘create_neb_section’: input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at fold-const.c:2150 in fact, this is on a file added to the CP2K CVS repo 2 days ago, so it is not yet part of the gzip'ed file that I provided for the initial report. That one compiles OK at -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/30147] [regression 4.3] ICE in fold_convert with -O2
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-11 16:19 --- #2 0x007395cf in fold_read_from_constant_string (exp=0x2ab7c225bd00) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:12854 12854 return fold_convert (TREE_TYPE (exp), (gdb) call debug_generic_expr (exp) *(charD.21[1:1] *) K #1 0x006c380a in fold_convert (type=0x2ab7c224f000, arg=0x2ab7c2260ae0) at /space/rguenther/src/svn/trunk/gcc/fold-const.c:2150 2150 gcc_unreachable (); (gdb) call debug_generic_expr (type) charD.21[1:1] (gdb) call debug_generic_expr (arg) 75 fold_convert does not know how to fold to char[1:1]. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-11 16:19:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30147
[Bug middle-end/30147] [regression 4.3] ICE in fold_convert with -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-11 16:25 ---
This fixes it:
Index: fold-const.c
===
*** fold-const.c(revision 119733)
--- fold-const.c(working copy)
*** fold_unary_to_constant (enum tree_code c
*** 12726,12732
tree
fold_read_from_constant_string (tree exp)
{
! if (TREE_CODE (exp) == INDIRECT_REF || TREE_CODE (exp) == ARRAY_REF)
{
tree exp1 = TREE_OPERAND (exp, 0);
tree index;
--- 12817,12825
tree
fold_read_from_constant_string (tree exp)
{
! if ((TREE_CODE (exp) == INDIRECT_REF
!|| TREE_CODE (exp) == ARRAY_REF)
!!AGGREGATE_TYPE_P (TREE_TYPE (exp)))
{
tree exp1 = TREE_OPERAND (exp, 0);
tree index;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30147
[Bug middle-end/30147] [4.3 Regression] ICE in fold_convert with -O2
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[regression 4.3] ICE in |[4.3 Regression] ICE in |fold_convert with -O2 |fold_convert with -O2 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30147
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
-- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-11 16:52:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug libstdc++/28265] iconv-related errors while building a cross-compiler for MinGW
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-12-11 16:53 --- Created an attachment (id=12782) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12782action=view) Patch to remove AC_CHECK_LIB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28265
[Bug c/30148] New: parameter passing bug
The following code tests that values are passed correctly from a
call to a function. This fails, when the followign code is
compiled with -O2 and executed:
foo: foo.c:65: callee_b0f: Assertion `b14.b3 == b20.b3' failed.
The code below is automatically generated explicitly to test for
parameter-passing bugs. Since the pre-processed code below might be
hard to understand, here is the orginal code as well.
/* These macros are defined in Lua string Quest.header, which may be
* re-defined from the quest command line or in file quest.lua.
*/
#ifndef QUEST_FAILED
#include assert.h
#define QUEST_ASSERT(x) assert(x)
#else
#define QUEST_ASSERT(x) if (!(x)) failed(__LINE__)
#endif
#include stdarg.h
extern int printf(char *, ...);
static int errors = 0;
static void failed(int line)
{ printf(failed in %s: %d\n, __FILE__, line); errors++; }
static union bt7 { unsigned long int b10; double *b11; } b12 = {1989374529UL};
static
struct bt5 { unsigned int *b7; unsigned int b8; signed b9:10; } b17
= {(unsigned int *) 229073790U, 777271108U, 408};
static union bt6 { } b18 = {};
static union bt0 { } b13 = {};
static
struct bt3
{
float b3;
struct bt1 { short int b0; signed b1:2; } b4;
struct bt2 { float b2; } b5;
}
b14
= {10569.23, {17187, 1}, {45076.89}};
static union bt4 { double b6; } b15 = {92314.64};
static double b16 = 89201.46;
union bt7 callee_b0f(struct bt5 bp2, union bt6 bp3, ...)
{
va_list ap;
typedef union bt0 bd0;
typedef struct bt3 bd1;
typedef union bt4 bd2;
typedef double bd3;
bd0 b19;
bd1 b20;
bd2 b21;
bd3 b22;
/* seed: 4346181125667919790 */
va_start(ap, bp3);
QUEST_ASSERT(b17.b7 == bp2.b7);
QUEST_ASSERT(b17.b8 == bp2.b8);
QUEST_ASSERT(b17.b9 == bp2.b9);
b19 = va_arg(ap, bd0);
b20 = va_arg(ap, bd1);
b21 = va_arg(ap, bd2);
b22 = va_arg(ap, bd3);
QUEST_ASSERT(b14.b3 == b20.b3);
QUEST_ASSERT(b14.b4.b0 == b20.b4.b0);
QUEST_ASSERT(b14.b4.b1 == b20.b4.b1);
QUEST_ASSERT(b14.b5.b2 == b20.b5.b2);
QUEST_ASSERT(b15.b6 == b21.b6);
QUEST_ASSERT(b16 == b22);
va_end(ap);
return b12;
}
static void caller_b1f()
{
union bt7 b23;
/* seed: 4346181125667919790 */
b23 = callee_b0f(b17, b18, b13, b14, b15, b16);
QUEST_ASSERT(b12.b10 == b23.b10);
}
int main(int argc, char **argv) { caller_b1f(); return errors; }
Below is the pre-processed code:
# 1 foo.c
# 1 built-in
# 1 command line
# 1 foo.c
# 15 foo.c
# 1 /usr/include/assert.h 1 3 4
# 36 /usr/include/assert.h 3 4
# 1 /usr/include/features.h 1 3 4
# 308 /usr/include/features.h 3 4
# 1 /usr/include/sys/cdefs.h 1 3 4
# 309 /usr/include/features.h 2 3 4
# 331 /usr/include/features.h 3 4
# 1 /usr/include/gnu/stubs.h 1 3 4
# 332 /usr/include/features.h 2 3 4
# 37 /usr/include/assert.h 2 3 4
# 67 /usr/include/assert.h 3 4
extern void __assert_fail (__const char *__assertion, __const char *__file,
unsigned int __line, __const char *__function)
__attribute__ ((__nothrow__)) __attribute__ ((__noreturn__));
extern void __assert_perror_fail (int __errnum, __const char *__file,
unsigned int __line,
__const char *__function)
__attribute__ ((__nothrow__)) __attribute__ ((__noreturn__));
extern void __assert (const char *__assertion, const char *__file, int __line)
__attribute__ ((__nothrow__)) __attribute__ ((__noreturn__));
# 16 foo.c 2
# 1 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/include/stdarg.h 1 3 4
# 43 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/include/stdarg.h 3 4
typedef __builtin_va_list __gnuc_va_list;
# 105 /usr/lib/gcc/x86_64-linux-gnu/4.1.2/include/stdarg.h 3 4
typedef __gnuc_va_list va_list;
# 22 foo.c 2
extern int printf(char *, ...);
static int errors = 0;
static void failed(int line)
{ printf(failed in %s: %d\n, foo.c, line); errors++; }
static union bt7 { unsigned long int b10; double *b11; } b12 = {1989374529UL};
static
struct bt5 { unsigned int *b7; unsigned int b8; signed b9:10; } b17
= {(unsigned int *) 229073790U, 777271108U, 408};
static union bt6 { } b18 = {};
static union bt0 { } b13 = {};
static
struct bt3
{
float b3;
struct bt1 { short int b0; signed b1:2; } b4;
struct bt2 { float b2; } b5;
}
b14
= {10569.23, {17187, 1}, {45076.89}};
static union bt4 { double b6; } b15 = {92314.64};
static double b16 = 89201.46;
union bt7 callee_b0f(struct bt5 bp2, union bt6 bp3, ...)
{
va_list ap;
typedef union bt0 bd0;
typedef struct bt3 bd1;
typedef union bt4 bd2;
typedef double bd3;
bd0 b19;
bd1 b20;
bd2 b21;
bd3 b22;
__builtin_va_start(ap,bp3);
((void) ((b17.b7 == bp2.b7) ? 0 : (__assert_fail (b17.b7 == bp2.b7,
foo.c, 58, __PRETTY_FUNCTION__), 0)));
((void) ((b17.b8 == bp2.b8) ? 0 : (__assert_fail (b17.b8 == bp2.b8,
foo.c, 59, __PRETTY_FUNCTION__), 0)));
((void) ((b17.b9 == bp2.b9) ? 0 : (__assert_fail (b17.b9 ==
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #4 from bkoz at gcc dot gnu dot org 2006-12-11 16:55 --- Created an attachment (id=12783) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12783action=view) Patch to remove AC_CHECK_LIB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Comment #44 from hjl at lucon dot org 2006-12-11 17:04 --- This patch http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00594.html doesn't cause any regressions on AIX nor HPUX: http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00595.html http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00754.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug middle-end/30149] New: tree-cfg.c:1924: ICE: in cse_find_path, at cse.c:5930
/home/dave/gcc-4.3/objdir/./prev-gcc/xgcc -B/home/dave/gcc-4.3/objdir/./prev-gcc / -B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/ -c -g -O2 -DIN_GCC -W - Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-lon g-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmis sing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/ gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/inclu de -I../../gcc/gcc/../libdecnumber -I../libdecnumber ../../gcc/gcc/tree-eh.c -o tree-eh.o ../../gcc/gcc/tree-cfg.c: In function 'remove_useless_stmts_1': ../../gcc/gcc/tree-cfg.c:1924: internal compiler error: in cse_find_path, at cse .c:5930 #0 fancy_abort (file=0xa79740 ../../gcc/gcc/cse.c, line=5930, function=0xa79834 cse_find_path) at ../../gcc/gcc/diagnostic.c:642 #1 0x0036985c in cse_find_path (first_bb=0x40ff1cf0, data=0xc01ddfdc, follow_jumps=1) at ../../gcc/gcc/cse.c:5930 #2 0x0036a964 in cse_main (f=0x40d7d660, nregs=685) at ../../gcc/gcc/cse.c:6209 #3 0x0036cbe8 in rest_of_handle_cse () at ../../gcc/gcc/cse.c:6967 #4 0x00768fe4 in execute_one_pass (pass=0xb09e70) at ../../gcc/gcc/passes.c:858 #5 0x00769200 in execute_pass_list (pass=0xb09e70) at ../../gcc/gcc/passes.c:902 #6 0x00769234 in execute_pass_list (pass=0xb0b14c) at ../../gcc/gcc/passes.c:903 #7 0x00172800 in tree_rest_of_compilation (fndecl=0x409aeaf0) at ../../gcc/gcc/tree-optimize.c:463 #8 0x0004d2cc in c_expand_body (fndecl=0x409aeaf0) at ../../gcc/gcc/c-decl.c:6855 #9 0x00801f84 in cgraph_expand_function (node=0x40cba180) at ../../gcc/gcc/cgraphunit.c:1096 #10 0x0080232c in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1161 #11 0x008032fc in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1440 #12 0x00051428 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:7968 ---Type return to continue, or q return to quit--- #13 0x006d9dc4 in compile_file () at ../../gcc/gcc/toplev.c:1040 #14 0x006dc8a0 in do_compile () at ../../gcc/gcc/toplev.c:2089 #15 0x006dc94c in toplev_main (argc=39, argv=0xc01dd760) at ../../gcc/gcc/toplev.c:2121 #16 0x00123930 in main (argc=39, argv=0xc01dd760) at ../../gcc/gcc/main.c:35 Looks to be the same problem as reported on gcc list for mipsel-linux. -- Summary: tree-cfg.c:1924: ICE: in cse_find_path, at cse.c:5930 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30149
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-11 18:00 --- still reducing it, I have it down to 8521 lines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #42 from dberlin at gcc dot gnu dot org 2006-12-11 18:13 --- This bug (against the regular development branches) should not be marked fixed simply because a patch was applied to the redhat branch. Either it needs to go into mainline 4.1, or the bug needs to be closed in some other manner. I am simply reopening it because it looks like it hasn't actually been resolved. I have no opinion on any of the actual issues involved :) -- dberlin at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug middle-end/30149] tree-cfg.c:1924: ICE: in cse_find_path, at cse.c:5930
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-11 18:17 --- Created an attachment (id=12784) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12784action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30149
[Bug middle-end/30149] [4.3 Regression] tree-cfg.c:1924: ICE: in cse_find_path, at cse.c:5930
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30149
[Bug middle-end/30149] [4.3 Regression] tree-cfg.c:1924: ICE: in cse_find_path, at cse.c:5930
-- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-11 18:36:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30149
[Bug middle-end/30151] New: /usr/ccs/bin/ld: Duplicate symbol global destructors keyed to _ZNSt3tr112_GLOBA L__N_16ignoreE
Executing on host: /xxx/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/xxx/gnu/gcc/o bjdir/./gcc -nostdinc++ -L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/ src -L/xxx/gnu/gcc/objdir/hppa1.1-hp-hpux10.20/libstdc++-v3/src/.libs -B/opt/gnu /gcc/gcc-4.3.0/hppa1.1-hp-hpux10.20/bin/ -B/opt/gnu/gcc/gcc-4.3.0/hppa1.1-hp-hpu x10.20/lib/ -isystem /opt/gnu/gcc/gcc-4.3.0/hppa1.1-hp-hpux10.20/include -isyste m /opt/gnu/gcc/gcc-4.3.0/hppa1.1-hp-hpux10.20/sys-include -g -O2 -D_GLIBCXX_ASSE RT -fmessage-length=0 -g -O2 -DLOCALEDIR=. -nostdinc++ -I/xxx/gnu/gcc/objdir/h ppa1.1-hp-hpux10.20/libstdc++-v3/include/hppa1.1-hp-hpux10.20 -I/xxx/gnu/gcc/obj dir/hppa1.1-hp-hpux10.20/libstdc++-v3/include -I/xxx/gnu/gcc/gcc/libstdc++-v3/li bsupc++ -I/xxx/gnu/gcc/gcc/libstdc++-v3/include/backward -I/xxx/gnu/gcc/gcc/libs tdc++-v3/testsuite/util /xxx/gnu/gcc/gcc/libstdc++-v3/testsuite/23_containers/de que/check_construct_destroy.cc-include bits/stdc++.h ./libtestc++.a -lm - o ./check_construct_destroy.exe(timeout = 600) /usr/ccs/bin/ld: Duplicate symbol global destructors keyed to _ZNSt3tr112_GLOBA L__N_16ignoreE in files /var/tmp//ccsKVWMm.o and ./libtestc++.a(testsuite_alloc ator.o) /usr/ccs/bin/ld: Duplicate symbol global constructors keyed to _ZNSt3tr112_GLOB AL__N_16ignoreE in files /var/tmp//ccsKVWMm.o and ./libtestc++.a(testsuite_allo cator.o) /usr/ccs/bin/ld: Found 2 duplicate symbol(s) collect2: ld returned 1 exit status compiler exited with status 1 output is: /usr/ccs/bin/ld: Duplicate symbol global destructors keyed to _ZNSt3tr112_GLOBA L__N_16ignoreE in files /var/tmp//ccsKVWMm.o and ./libtestc++.a(testsuite_alloc ator.o) /usr/ccs/bin/ld: Duplicate symbol global constructors keyed to _ZNSt3tr112_GLOB AL__N_16ignoreE in files /var/tmp//ccsKVWMm.o and ./libtestc++.a(testsuite_allo cator.o) /usr/ccs/bin/ld: Found 2 duplicate symbol(s) collect2: ld returned 1 exit status FAIL: 23_containers/deque/check_construct_destroy.cc (test for excess errors) This also causes the failure of these tests: FAIL: 23_containers/list/check_construct_destroy.cc (test for excess errors) FAIL: 23_containers/set/check_construct_destroy.cc (test for excess errors) FAIL: 23_containers/vector/capacity/2.cc (test for excess errors) FAIL: 23_containers/vector/check_construct_destroy.cc (test for excess errors) FAIL: 23_containers/vector/cons/4.cc (test for excess errors) FAIL: ext/hash_set/check_construct_destroy.cc (test for excess errors) FAIL: ext/slist/check_construct_destroy.cc (test for excess errors) ... It looks like we need unique global names for type N as well as F. -- Summary: /usr/ccs/bin/ld: Duplicate symbol global destructors keyed to _ZNSt3tr112_GLOBA L__N_16ignoreE Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
[Bug bootstrap/30152] New: bootstrap of trunk broken on Solaris x86 - varasm.c
bootstrap of trunk broken on Solaris x86 as of 12/8/06, I believe. It looks like varasm.c is giving warnings: /u01/var/tmp/gcc_trunk_svn/gcc_20061211/./prev-gcc/xgcc -B/u01/var/tmp/gcc_trunk_svn/gcc_20061211/./prev-gcc/ -B/opt/gcc-4.3/i386-pc-solaris2.10/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc/. -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc/../include -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I/u01/var/tmp/gcc_trunk_svn/gcc/gcc/../libdecnumber -I../libdecnumber/u01/var/tmp/gcc_trunk_svn/gcc/gcc/varasm.c -o varasm.o cc1: warnings being treated as errors /u01/var/tmp/gcc_trunk_svn/gcc/gcc/varasm.c: In function 'elf_record_gcc_switches': /u01/var/tmp/gcc_trunk_svn/gcc/gcc/varasm.c:6268: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'long int' /u01/var/tmp/gcc_trunk_svn/gcc/gcc/varasm.c:6275: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'long int' /u01/var/tmp/gcc_trunk_svn/gcc/gcc/varasm.c:6283: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'long int' /u01/var/tmp/gcc_trunk_svn/gcc/gcc/varasm.c:6302: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'long int' gmake[3]: *** [varasm.o] Error 1 gmake[3]: Leaving directory `/u01/var/tmp/gcc_trunk_svn/gcc_20061211/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 Brett -- Summary: bootstrap of trunk broken on Solaris x86 - varasm.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brett dot albertson at stratech dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30152
[Bug c++/20724] function overload resolution fails when any template is declared
--- Comment #7 from s__nakayama at infoseek dot jp 2006-12-11 19:21 --- Is this still active? gcc 4.1.1 accept Andrew's testcase in comment #1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20724
[Bug c/30153] New: -fPIC failure
cat gcc.c
static inline void foo (void) { }
void baz (void (*f) (void));
void bar (void) { baz (foo); }
gcc -O0 -c -fPIC gcc.c
gcc -shared -o gcc.so gcc.o
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld:
gcc.o: relocation R_X86_64_PC32 against `foo' can not be used when making a
shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/4.1.0/../../../../x86_64-suse-linux/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status
Note: Adding -02 to the compilation silences this.
Note: Removing inline silences this.
--
Summary: -fPIC failure
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30153
[Bug c/30116] faulty -Wformat warning with pointers to arrays
--- Comment #2 from herring at lanl dot gov 2006-12-11 19:24 --- (In reply to comment #1) *** This bug has been marked as a duplicate of 27558 *** Thanks for finding that for me! I tried for an hour to locate this bug in the database (because I discovered it some time ago; presumably I would have reported it then if it weren't already there, and I hadn't), but to no avail. Apologies for the noise, but at least now I can watch the original report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30116
[Bug bootstrap/30152] [4.3 Regression] bootstrap of trunk broken on Solaris x86 - varasm.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-11 19:29 --- Just fixed by: http://gcc.gnu.org/ml/gcc-cvs/2006-12/msg00364.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Summary|bootstrap of trunk broken on|[4.3 Regression] bootstrap |Solaris x86 - varasm.c |of trunk broken on Solaris ||x86 - varasm.c Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30152
[Bug c++/30139] overflow warning for unevaluated part of expression
--- Comment #2 from manu at gcc dot gnu dot org 2006-12-11 19:35 ---
(In reply to comment #1)
I think the C front-end is incorrect in not warning, though someone has to
look
into the standard to be sure.
Is there a searchable version of the standard?
Anyway, the following code snippet from Joseph Myers at
testsuite/gcc.dg/overflow-warn-1.c seems to imply otherwise:
enum e {
/* Overflow in an unevaluated part of an expression is OK (example
in the standard). */
E2 = 2 || 1 / 0
};
/* The first two of these involve overflow, so are not null pointer
constants. The third has the overflow in an unevaluated
subexpression, so is a null pointer constant. */
void *p = 0 * (INT_MAX + 1); /* { dg-warning warning: integer overflow in
expression } */
/* { dg-warning warning: initialization makes pointer from integer without a
cast null { target *-*-* } 48 } */
void *q = 0 * (1 / 0); /* { dg-warning warning: division by zero } */
/* { dg-warning warning: initialization makes pointer from integer without a
cast null { xfail *-*-* } 50 } */
void *r = (1 ? 0 : INT_MAX+1);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30139
[Bug middle-end/27657] [4.2/4.3 regression] bogus undefined reference error to static var with -g and -O
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-12-11 20:23
---
Btw, the following C++ example fails to link even without -O:
=
const char s[] = ;
const char *const p = s;
int main()
{
return 0;
}
=
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Keywords||monitored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27657
[Bug target/28181] [4.0/4.1/4.2/4.3 regression] ICE in reload_cse_simplify_operands, at postreload.c:393 on m68k
--- Comment #9 from rask at sygehus dot dk 2006-12-11 20:24 --- Created an attachment (id=12785) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12785action=view) Partial patch Please try this patch. It removes the ICE, but the code may not run on 68000 and 68010 CPUs because there is also an alignment problem. Please see URL:http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00766.html for details. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28181
[Bug middle-end/30151] /usr/ccs/bin/ld: Duplicate symbol global destructors keyed to _ZNSt3tr112_GLOBAL__N_16ignoreE
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-11 20:32 --- It seems that the special handling for 'F' was removed... 2006-10-31 Geoffrey Keating [EMAIL PROTECTED] ... * tree.c (get_file_function_name): Rename from get_file_function_name_long; improve comment; handle 'I' and 'D' specially when the target has ctor/dtor support; remove special handling for 'F'. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Summary|/usr/ccs/bin/ld: Duplicate |/usr/ccs/bin/ld: Duplicate |symbol global destructors |symbol global destructors |keyed to _ZNSt3tr112_GLOBA |keyed to |L__N_16ignoreE |_ZNSt3tr112_GLOBAL__N_16igno ||reE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
[Bug c/19976] integer division by zero in subexpression should be overflow
--- Comment #8 from manu at gcc dot gnu dot org 2006-12-11 20:52 ---
(In reply to comment #5)
int x;
enum e { E = 0 * x };
which currently compiles without even a warning using -pedantic-errors.
This is exactly the sort of thing that Joseph's struct c_expr were intended
to handle. I don't think is unreasonable for fold to convert 0 * x into
0, the issue is that a front-end can't really look at a folded tree and
determine anything much about the original source code.
Should it warn?
But back to the original case, we detect enum e { E = 0 * (INT_MAX + 1) }; by
setting TREE_OVERFLOW. We could do the same for 1/0 and we just don't emit an
overflow warning but a division by zero one. But this could be tricky.
However, an alternative would be to prevent the folding for this specific case,
so the resulting tree is not constant. We could try to detect this when folding
0*x (not sure how), or we could build something from 1/0 that will prevent
folding 0*x (if such thing exists).
Am I missing any other alternatives?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19976
[Bug fortran/29711] [4.2 only] error_print does not support %N$X
--- Comment #13 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:57 --- Subject: Bug 29711 Author: fxcoudert Date: Mon Dec 11 20:57:10 2006 New Revision: 119747 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119747 Log: PR fortran/29892 * trans-intrinsic.c (gfc_conv_intrinsic_bound): Use a locus in the call to gfc_trans_runtime_check. * trans-array.c (gfc_trans_array_bound_check): Try harder to find the variable or function name for the runtime error message. (gfc_trans_dummy_array_bias): Use a locus in the call to gfc_trans_runtime_check PR fortran/29973 * resolve.c (resolve_actual_arglist): Remove the special case for CHAR. * intrinsic.c (add_functions): Remove the special case for CHAR. PR fortran/29711 * error.c (error_print): Handle printf-style position specifiers, of the form %3$d. PR fortran/29973 * gfortran.dg/specifics_1.f90: Remove check for CHAR. * gfortran.dg/specifics_2.f90: Remove check for CHAR. * gfortran.dg/specifics_3.f90: Remove. * gfortran.fortran-torture/execute/specifics.f90: Remove test for CHAR. Removed: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/specifics_3.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/error.c branches/gcc-4_2-branch/gcc/fortran/intrinsic.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-array.c branches/gcc-4_2-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/specifics_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/specifics_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug fortran/29892] substring out of bounds: Missing variable name for variables with parameter attribute
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:57 --- Subject: Bug 29892 Author: fxcoudert Date: Mon Dec 11 20:57:10 2006 New Revision: 119747 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119747 Log: PR fortran/29892 * trans-intrinsic.c (gfc_conv_intrinsic_bound): Use a locus in the call to gfc_trans_runtime_check. * trans-array.c (gfc_trans_array_bound_check): Try harder to find the variable or function name for the runtime error message. (gfc_trans_dummy_array_bias): Use a locus in the call to gfc_trans_runtime_check PR fortran/29973 * resolve.c (resolve_actual_arglist): Remove the special case for CHAR. * intrinsic.c (add_functions): Remove the special case for CHAR. PR fortran/29711 * error.c (error_print): Handle printf-style position specifiers, of the form %3$d. PR fortran/29973 * gfortran.dg/specifics_1.f90: Remove check for CHAR. * gfortran.dg/specifics_2.f90: Remove check for CHAR. * gfortran.dg/specifics_3.f90: Remove. * gfortran.fortran-torture/execute/specifics.f90: Remove test for CHAR. Removed: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/specifics_3.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/error.c branches/gcc-4_2-branch/gcc/fortran/intrinsic.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-array.c branches/gcc-4_2-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/specifics_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/specifics_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29892
[Bug fortran/29973] [4.2 only] CHAR not allowed as actual argument, even in F2003
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:57 --- Subject: Bug 29973 Author: fxcoudert Date: Mon Dec 11 20:57:10 2006 New Revision: 119747 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119747 Log: PR fortran/29892 * trans-intrinsic.c (gfc_conv_intrinsic_bound): Use a locus in the call to gfc_trans_runtime_check. * trans-array.c (gfc_trans_array_bound_check): Try harder to find the variable or function name for the runtime error message. (gfc_trans_dummy_array_bias): Use a locus in the call to gfc_trans_runtime_check PR fortran/29973 * resolve.c (resolve_actual_arglist): Remove the special case for CHAR. * intrinsic.c (add_functions): Remove the special case for CHAR. PR fortran/29711 * error.c (error_print): Handle printf-style position specifiers, of the form %3$d. PR fortran/29973 * gfortran.dg/specifics_1.f90: Remove check for CHAR. * gfortran.dg/specifics_2.f90: Remove check for CHAR. * gfortran.dg/specifics_3.f90: Remove. * gfortran.fortran-torture/execute/specifics.f90: Remove test for CHAR. Removed: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/specifics_3.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/error.c branches/gcc-4_2-branch/gcc/fortran/intrinsic.c branches/gcc-4_2-branch/gcc/fortran/resolve.c branches/gcc-4_2-branch/gcc/fortran/trans-array.c branches/gcc-4_2-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/specifics_1.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/specifics_2.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.fortran-torture/execute/specifics.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29973
[Bug fortran/29711] [4.2 only] error_print does not support %N$X
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:58 --- Commited to 4.2, both my patch and Tobias' fix. Thanks Tobias for fixing it! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29711
[Bug fortran/29973] [4.2 only] CHAR not allowed as actual argument, even in F2003
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-12-11 20:58 --- Fixed on 4.2 also. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29973
[Bug c++/27961] [4.1 regression] ICE on invalid template declaration
--- Comment #8 from reichelt at gcc dot gnu dot org 2006-12-11 21:00
---
Fixed on mainline.
Alas this is only partially true:
Although the original testcase is indeed fixed on mainline (and 4.2 branch),
the following variant (which only differs in the return type of the template
function) still crashes:
struct A
{
templateint int foo(X);
};
I'll open a new PR for this failure.
Btw, the testcase from comment #1 is also fixed on the 4.1 branch
(with void or int as return type).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #10 from bkoz at gcc dot gnu dot org 2006-12-11 21:02 --- Diego I HEART YOU r119746 fixes it. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-12-11 21:06 --- (In reply to comment #10) Diego I HEART YOU r119746 But I think it just makes the bug latent again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug c++/30156] New: [4.1/4.2/4.3 regression] ICE on invalid template declaration
The following invalid testcase causes an ICE on the 4.1 branch, 4.2 branch
and mainline (4.1.0 and 4.1.1 are not affected, though):
struct A
{
templateint int foo(X);
};
The underlying problem is the same as in PR27961, but cannot be papered
over as easily in this case ;-)
--
Summary: [4.1/4.2/4.3 regression] ICE on invalid template
declaration
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
BugsThisDependsOn: 27961
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30156
[Bug c++/30156] [4.1/4.2/4.3 regression] ICE on invalid template declaration
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30156
[Bug c++/30156] [4.1/4.2/4.3 regression] ICE on invalid template declaration
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-12-11 21:12 --- Sorry, forgot to add the error message: bug.cc:3: error: 'X' was not declared in this scope bug.cc:3: internal compiler error: tree check: expected var_decl, have field_decl in cp_finish_decl, at cp/decl.c:5092 Please submit a full bug report, [etc.] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30156
[Bug testsuite/30157] New: cxa_atexit check doesn't work
The following tests fail on hppa1.1-hp-hpux10.20: FAIL: g++.old-deja/g++.other/init18.C execution test FAIL: g++.old-deja/g++.other/init19.C execution test FAIL: g++.old-deja/g++.other/init5.C execution test These tests are xfailed on targets that don't support cxa_atexit using using the check_cxa_atexit_available. This target doesn't have cxa_atexit, so the chack should xfail these tests. -- Summary: cxa_atexit check doesn't work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa1.1-hp-hpux10.20 GCC host triplet: hppa1.1-hp-hpux10.20 GCC target triplet: hppa1.1-hp-hpux10.20 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30157
[Bug c++/30158] New: [4.0/4.1/4.2/4.3 regression] ICE with invalid statement-expressions
The following invalid code snippet triggers an ICE since GCC 4.0.0
(and in GCC 3.4.0 - 3.4.3):
===
void foo(int i)
{
(i ? 1 : 2) = ({ X; });
}
===
bug.cc: In function 'void foo(int)':
bug.cc:3: error: 'X' was not declared in this scope
bug.cc:3: internal compiler error: in build_target_expr_with_type, at
cp/tree.c:326
Please submit a full bug report, [etc.]
An ICE in the same place can be triggered with the following code snippet:
===
struct A
{
~A ();
void foo()
{
delete this = ({ X; });
}
};
===
bug.cc: In member function 'void A::foo()':
bug.cc:6: error: 'X' was not declared in this scope
bug.cc:6: internal compiler error: in build_target_expr_with_type, at
cp/tree.c:326
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2/4.3 regression] ICE with invalid statement-
expressions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30158
[Bug c++/30158] [4.0/4.1/4.2/4.3 regression] ICE with invalid statement-expressions
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30158
[Bug rtl-optimization/30113] ICE in trunc_int_for_mode
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-12-11 21:29 --- Subject: Bug 30113 Author: rakdver Date: Mon Dec 11 21:29:44 2006 New Revision: 119748 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119748 Log: PR rtl-optimization/30113 * loop-iv.c (implies_p): Require the mode of the operands to be scalar. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-iv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30113
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #5 from bkoz at gcc dot gnu dot org 2006-12-11 21:55 --- Created an attachment (id=12786) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12786action=view) Patch++ -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Attachment #12783|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #12 from bkoz at gcc dot gnu dot org 2006-12-11 22:16 --- But I think it just makes the bug latent again. maybe. But I can compile again so I will close this. -benjamin -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug libstdc++/28125] Cannot build cross compiler for Solaris: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-12-11 22:17 --- Subject: Bug 28125 Author: bkoz Date: Mon Dec 11 22:17:09 2006 New Revision: 119749 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119749 Log: 2006-12-11 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/28125 * acinclude.m4 (GLIBCXX_CHECK_ICONV_SUPPORT): Remove link test, ie AC_CHECK_LIB for libiconv. Instead, use bits of AM_ICONV. * configure: Regenerate. * scripts/testsuite_flags.in (cxxldflags): Add LIBICONV bits. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/scripts/testsuite_flags.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28125
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-12-11 23:15 --- As far as I can see, we are miscompiling the compiler as the stage1's cc1 works for this testcase but stage3's cc1 does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug middle-end/30147] [4.3 Regression] ICE in fold_convert with -O2
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-12-11 23:17 --- This is caused by 2006-05-09 Dirk Mueller [EMAIL PROTECTED] Richard Guenther [EMAIL PROTECTED] PR middle-end/27498 * fold-const.c (fold_read_from_constant_string): Relax check for matching types to matching modes. and the fix is probably correct. Mine. 4.2 should be also affected really. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-12-11 16:19:11 |2006-12-11 23:17:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30147
[Bug c++/30156] [4.1/4.2/4.3 regression] ICE on invalid template declaration
--- Comment #2 from lmillward at gcc dot gnu dot org 2006-12-11 23:17 --- I did post a patch to fix this following your comments on the patch for PR27961 here - http://gcc.gnu.org/ml/gcc-patches/2006-10/msg00867.html. It seems like this one slipped through the cracks. I'll give it another bootstrap and regression test against current mainline and resubmit. -- lmillward at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |lmillward at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-11 23:17:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30156
[Bug middle-end/30147] [4.3 Regression] ICE in fold_convert with -O2
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-11 23:20 --- Instead of mode checking, what about checking the code of the type inaddition, though maybe checking the for INTEGERAL_TYPE_P before the check for the mode will also fix this issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30147
[Bug tree-optimization/30159] New: [4.3 Regression] gcc.c-torture/execute/20010422-1.c is miscompiled on sh-elf and mips-elf
On sh-elf, the function foo in 20010422-1.c
unsigned int foo(unsigned int x)
{
if (x 5)
x = 4;
else
x = 8;
return x;
}
is compiled to
foo:
mov.l r14,@-r15
mov r15,r14
mov #4,r1
cmp/hi r1,r1
bf/s.L6
mov #4,r0
mov #8,r0
.L6:
mov r14,r15
mov.l @r15+,r14
rts
nop
with -O1. Thus the first parameter register r4 is ignored.
For mips-elf, foo is assembled to
foo:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
sltu$2,$2,5
beq $2,$0,$L2
nop
...
with -O1 where $4 should be register for x.
It started after the patch
r119711 | amacleod | 2006-12-11 06:25:40 +0900 (Mon, 11 Dec 2006) | 103 lines
and the first tree dump which differs before and after this patch
is .099t.optimized:
[r119710 .099t.optimized]
;; Function foo (foo)
Analyzing Edge Insertions.
foo (x)
{
unsigned int x.24;
bb 2:
if (x = 4) goto L5; else goto L4;
L5:;
x.24 = 4;
goto bb 4 (L2);
L4:;
x.24 = 8;
L2:;
return x.24;
}
[r119711 .099t.optimized]
;; Function foo (foo)
Analyzing Edge Insertions.
foo (x)
{
unsigned int x.24;
bb 2:
if (x.24 = 4) goto L5; else goto L4;
L5:;
x = 4;
goto bb 4 (L2);
L4:;
x = 8;
L2:;
return x;
}
--
Summary: [4.3 Regression] gcc.c-torture/execute/20010422-1.c is
miscompiled on sh-elf and mips-elf
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kkojima at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: sh-elf, mips-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30159
[Bug c/30160] New: enum reporting sizeof == 0
Hello,
I'm compiling on cygwin on my Dell Laptop. I'm running windows xp pro, with
the 3.4.4 version of gcc
my source file:
#include stdio.h
typedef enum {
ac = -1,
ab = 0x,
aa = 1,
} en;
int main()
{
en a = ab;
printf(a = %d sizeof %d\n, a, sizeof(en));
return 0;
}
$ gcc -Wall test.c
test.c: In function `main':
test.c:11: warning: int format, different type arg (arg 2)
$ ./a.exe
a = -1 sizeof 0
shouldn't sizeof be 4?
--
Summary: enum reporting sizeof == 0
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richard at beatnik dot com
GCC build triplet: 3.4.4
GCC host triplet: 3.4.4
GCC target triplet: 3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30160
[Bug c/30160] enum reporting sizeof == 0
--- Comment #1 from richard at beatnik dot com 2006-12-12 00:51 --- Created an attachment (id=12787) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12787action=view) test file for creating bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30160
[Bug c/30160] enum reporting sizeof == 0
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-12 01:01 --- 4.0 and above give a better warning message for this issue: t1.c:12: warning: format '%d' expects type 'int', but argument 2 has type 'long long int' This is not a bug in GCC but rather your code in that the enum you have is the same size as long long. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30160
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-12-12 01:22 --- Reopening for a second to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-12-12 01:22 --- Mark this as a dup of bug 28624. *** This bug has been marked as a duplicate of 28624 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug tree-optimization/28624] [4.2/4.3 regression] latent segfault in remove_phi_node
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-12 01:22 --- *** Bug 30126 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28624
[Bug tree-optimization/28624] [4.2/4.3 regression] latent segfault in remove_phi_node
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-12 01:24 --- The problem is EXECUTE_IF_SET_IN_BITMAP does not like the bitmap to change from underneath it. I have a patch which fixes this issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-12 01:24:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28624
[Bug c/30160] enum reporting sizeof == 0
--- Comment #3 from richard at beatnik dot com 2006-12-12 01:29 --- Ahh, I see. Because the a is supposed to be long long, that means that it is of size 8, which would mean that it takes two regs (or stack spaces, or where ever gcc stores it's arguments). Then the second %d in the string gets the second of the two args, thus being zero: - V | first half of the 8 byte argument printf( a = %d sizeof %d\n, a, sizeof(en)); ^ | second half of the 8 byte argument --- When I change to - V | the 8 byte argument printf( a = %lld sizeof %d\n, a, sizeof(en)); ^| -- Thanks -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30160
[Bug c++/29732] [4.0/4.1/4.2 regression] ICE on invalid friend declaration
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-12-12 01:47 --- Subject: Bug 29732 Author: mmitchel Date: Tue Dec 12 01:46:57 2006 New Revision: 119759 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119759 Log: PR c++/29732 * cp-tree.h (DECL_USE_TEMPLATE): Mention partial specializations. (explicit_class_specialization_p): Declare. * pt.c (explicit_class_specialization_p): New function. * parser.c (cp_parser_init_declarator): Check correct number of template parameters for in-class function definitions. (cp_parser_check_declarator_template_parameters): Stop looking for template classes when we find an explicit specialization. PR c++/29732 * g++.dg/template/crash65.C: New test. * g++.dg/template/spec16.C: Tweak error markers. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/crash65.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/parser.c branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/spec16.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29732
[Bug c++/29732] [4.0 regression] ICE on invalid friend declaration
--- Comment #6 from mmitchel at gcc dot gnu dot org 2006-12-12 01:53 --- Fixed in 4.1.2, 4.2.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|mark at codesourcery dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW Summary|[4.0/4.1/4.2 regression] ICE|[4.0 regression] ICE on |on invalid friend |invalid friend declaration |declaration | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29732
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Comment #45 from mmitchel at gcc dot gnu dot org 2006-12-12 02:14 --- This version is OK for mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug debug/30161] New: GCC should generate dwarf info about template parameters
GCC doesn't currently generate DW_TAG_template_*_param, and it should to improve C++ debuggability (and allow us to shorten the DW_AT_names of template instantiations). -- Summary: GCC should generate dwarf info about template parameters Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: debug AssignedTo: jason at gcc dot gnu dot org ReportedBy: jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30161
[Bug middle-end/17982] stop calling assemble_external before final assembly output time
--- Comment #29 from hjl at gcc dot gnu dot org 2006-12-12 03:59 --- Subject: Bug 17982 Author: hjl Date: Tue Dec 12 03:58:52 2006 New Revision: 119764 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119764 Log: 2006-12-11 H.J. Lu [EMAIL PROTECTED] PR middle-end/17982 PR middle-end/20218 * cgraphunit.c (cgraph_optimize): Remove call to process_pending_assemble_externals. * config/elfos.h (ASM_OUTPUT_EXTERNAL): New. * config/ia64/hpux.h (TARGET_ASM_FILE_END): Removed. * config/ia64/ia64.c (ia64_asm_output_external): Rewritten. (ia64_hpux_add_extern_decl): Removed. (ia64_hpux_file_end): Likewise. (extern_func_list): Likewise. (extern_func_head): Likewise. * output.h (assemble_external): Update comments. (default_elf_asm_output_external): New. (maybe_assemble_visibility): New. * toplev.c (compile_file): Update comment. * varasm.c (assemble_external): Always put it on pending_assemble_externals. (maybe_assemble_visibility): Make it extern and return int. (default_elf_asm_output_external): New. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/config/elfos.h trunk/gcc/config/ia64/hpux.h trunk/gcc/config/ia64/ia64.c trunk/gcc/output.h trunk/gcc/toplev.c trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17982
[Bug middle-end/20218] Can't use __attribute__ ((visibility (hidden))) to hide a symbol
--- Comment #46 from hjl at gcc dot gnu dot org 2006-12-12 03:59 --- Subject: Bug 20218 Author: hjl Date: Tue Dec 12 03:58:52 2006 New Revision: 119764 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=119764 Log: 2006-12-11 H.J. Lu [EMAIL PROTECTED] PR middle-end/17982 PR middle-end/20218 * cgraphunit.c (cgraph_optimize): Remove call to process_pending_assemble_externals. * config/elfos.h (ASM_OUTPUT_EXTERNAL): New. * config/ia64/hpux.h (TARGET_ASM_FILE_END): Removed. * config/ia64/ia64.c (ia64_asm_output_external): Rewritten. (ia64_hpux_add_extern_decl): Removed. (ia64_hpux_file_end): Likewise. (extern_func_list): Likewise. (extern_func_head): Likewise. * output.h (assemble_external): Update comments. (default_elf_asm_output_external): New. (maybe_assemble_visibility): New. * toplev.c (compile_file): Update comment. * varasm.c (assemble_external): Always put it on pending_assemble_externals. (maybe_assemble_visibility): Make it extern and return int. (default_elf_asm_output_external): New. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/config/elfos.h trunk/gcc/config/ia64/hpux.h trunk/gcc/config/ia64/ia64.c trunk/gcc/output.h trunk/gcc/toplev.c trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218
[Bug libfortran/30162] New: I/O with named pipes does not work
Reduced test case frim Bud Davis $ cat a.f integer status integer i open(unit=20,file='np',action='write', form='unformatted',iostat=status); print*,'status from open is ',status do i = 1,5 write(20)i end do end $ cat b.f integer status integer i integer val open(unit=21,file='np',action='read', form='unformatted',iostat=status); print*,'status from open is ',status do i = 1,5 read(21)val print*,val end do Here is what I get: $ mkfifo np $ ./b [1] 18730 $ ./a status from open is0 At line 7 of file a.f Fortran runtime error: Illegal seek status from open is0 At line 8 of file b.f Fortran runtime error: End of file -- Summary: I/O with named pipes does not work Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30162
[Bug libstdc++/28265] iconv-related errors while building a cross-compiler for MinGW
--- Comment #4 from rmathew at gcc dot gnu dot org 2006-12-12 04:52 --- Thanks for looking into this Ben. Unfortunately, I no longer build GCC for MinGW (or for Linux, for that matter) regularly so I'm unable to test your patch. :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28265
[Bug c++/30108] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #8 from bangerth at dealii dot org 2006-12-12 05:09 --- Confirmed. The code is valid. The code would have undefined runtime behavior if the default argument is a) actually used in a call to commonEventProcessing, and b) is used without any further cast. Neither is the case here, so the code is perfectly valid. In particular, it shouldn't ICE the compiler. This is a regression on all active branches w.r.t. 3.4.x. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.0.2 4.1.1 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-12-12 05:09:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c/30163] New: error at combine pass
I build a new target for experiment, and my GCC version is 4.1.1
I have one question
at combine pass , if
(set ( reg 1)
(and (reg 2)
(const_int 0x8001)))
(cmp (reg1 )(const_0)
if compare code is GE or LT
and src2 is zero
the const_int will be 0x8000
because it just need significant bit
but
if reg 1 will be used by following insns
the const_int shouldn't be modified.
following message are -daP result
at insn 13 that is my problem
-JASON-
--life pass
;; Function foo (foo)
120 registers.
Register 107 used 4 times across 6 insns; set 3 times.
Register 109 used 2 times across 2 insns in block 0; set 1 time; pointer.
Register 111 used 2 times across 2 insns in block 0; set 1 time.
Register 112 used 9 times across 11 insns; set 4 times.
Register 113 used 2 times across 2 insns in block 0; set 1 time.
Register 115 used 11 times across 17 insns; set 4 times.
Register 116 used 2 times across 2 insns in block 2; set 1 time.
Register 117 used 2 times across 2 insns in block 4; set 1 time.
Register 118 used 2 times across 2 insns in block 5; set 1 time.
10 basic blocks, 15 edges.
Basic block 0 prev -1, next 1, loop_depth 0, count 0, freq 1, maybe hot.
Predecessors: ENTRY [100.0%] (fallthru)
Successors: 2 [50.0%] 1 [50.0%] (fallthru)
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp]
Registers live at end: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 112
Basic block 1 prev 0, next 2, loop_depth 0, count 0, freq 5000, maybe hot.
Predecessors: 0 [50.0%] (fallthru)
Successors: 2 [100.0%] (fallthru)
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 112
Registers live at end: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 112
Basic block 2 prev 1, next 3, loop_depth 0, count 0, freq 1, maybe hot.
Predecessors: 0 [50.0%] 1 [100.0%] (fallthru)
Successors: 4 [50.0%] 3 [50.0%] (fallthru)
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 112
Registers live at end: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 115
Basic block 3 prev 2, next 4, loop_depth 0, count 0, freq 5000, maybe hot.
Predecessors: 2 [50.0%] (fallthru)
Successors: 4 [100.0%] (fallthru)
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 115
Registers live at end: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 115
Basic block 4 prev 3, next 5, loop_depth 0, count 0, freq 1, maybe hot.
Predecessors: 2 [50.0%] 3 [100.0%] (fallthru)
Successors: 8 [29.0%] 5 [71.0%] (fallthru)
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 115
Registers live at end: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 115
Basic block 5 prev 4, next 6, loop_depth 0, count 0, freq 7100, maybe hot.
Predecessors: 4 [71.0%] (fallthru)
Successors: 7 [71.0%] 6 [29.0%] (fallthru)
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 115
Registers live at end: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 115
Basic block 6 prev 5, next 7, loop_depth 0, count 0, freq 2059, maybe hot.
Predecessors: 5 [29.0%] (fallthru)
Successors: 9 [100.0%]
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 115
Registers live at end: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 107
Basic block 7 prev 6, next 8, loop_depth 0, count 0, freq 5041, maybe hot.
Predecessors: 5 [71.0%]
Successors: 9 [100.0%]
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp]
Registers live at end: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 107
Basic block 8 prev 7, next 9, loop_depth 0, count 0, freq 2900, maybe hot.
Predecessors: 4 [29.0%]
Successors: 9 [100.0%] (fallthru)
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp]
Registers live at end: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 107
Basic block 9 prev 8, next -2, loop_depth 0, count 0, freq 1, maybe hot.
Predecessors: 8 [100.0%] (fallthru) 6 [100.0%] 7 [100.0%]
Successors: EXIT [100.0%] (fallthru)
Registers live at start: 12 [fp] 14 [sp] 98 [sfp] 99 [afp] 107
Registers live at end: 0 [r0] 12 [fp] 14 [sp] 98 [sfp] 99 [afp]
try_optimize_cfg iteration 1
(note 2 0 6 NOTE_INSN_DELETED)
(note 6 2 9 NOTE_INSN_FUNCTION_BEG)
;; Start of basic block 0, registers live: 12 [fp] 14 [sp] 98 [sfp] 99 [afp]
(note 9 6 11 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn 11 9 12 0 (set (reg/f:SI 109)
(symbol_ref:SI (a) [flags 0x2] var_decl 0xb7dba0b0 a)) 68
{*movsi_var} (nil)
(nil))
(insn 12 11 13 0 (set (reg:SI 111 [ a ])
(mem/c/i:SI (reg/f:SI 109) [0 a+0 S4 A32])) 70 {*movsi}
(insn_list:REG_DEP_TRUE 11 (nil))
(expr_list:REG_DEAD (reg/f:SI 109)
(nil)))
(insn 13 12 14 0 (set (reg:SI 112)
(and:SI (reg:SI 111 [ a ])
(const_int -2147483647 [0x8001]))) 124 {andsi3}
(insn_list:REG_DEP_TRUE 12 (nil))
(expr_list:REG_DEAD (reg:SI 111 [ a ])
(nil)))
(insn 14 13 15 0 (set (reg:SI 113)
(const_int 0 [0x0])) 69 {*movsi_const} (nil)
(nil))
(insn 15 14 16 0 (set (reg:CC 97 r0cc)
(compare:CC (reg:SI 112)
(reg:SI 113))) 147 {*unicore_cmpsi_insn} (insn_list:REG_DEP_TRUE 13
(insn_list:REG_DEP_TRUE 14
[Bug tree-optimization/13962] [tree-ssa] make fold use alias information to optimize pointer comparisons
--- Comment #4 from dann at ics dot uci dot edu 2006-12-12 06:01 --- Subject: Re: [tree-ssa] make fold use alias information to optimize pointer comparisons steven at gcc dot gnu dot org [EMAIL PROTECTED] writes: --- Comment #3 from steven at gcc dot gnu dot org 2006-12-10 18:18 --- Is this fixed? No, it's not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13962
[Bug tree-optimization/30105] reassoc can sometimes get in the way of PRE
--- Comment #6 from dann at godzilla dot ics dot uci dot edu 2006-12-12
06:07 ---
(In reply to comment #5)
(In reply to comment #1)
Confirmed (but it's not PRE).
The second is smaller, and no more or less efficient since the addition is
calculated on both paths anyway.
Both are valid results, and what RTL does with them is it's business.
I don't believe you can claim they should generate identical assembly.
The actual thing this testcase is trying to test, that load-PRE is performed,
has succeeded.
Thus i am closing this bug as WORKSFORME.
If you see something *actually wrong* with the result, rather than just
disassembly, please feel free to reopen.
Here is a slightly modified example that shows that there's still a PRE
opportunity
void motion_test22(int * data, int i)
{
int j;
if (data[1]) {
data[data[2]] = 2;
j = data[0] * data[3];
i = i * j;
}
data[4] = data[0] * data[3];
data[5] = i;
}
L0:;
*((int *) ((unsigned int) *(data + 8B) * 4) + data) = 2;
prephitmp.26 = *data;
prephitmp.31 = *(data + 12B);
i = prephitmp.26 * i * prephitmp.31;
L1:;
*(data + 16B) = prephitmp.31 * prephitmp.26;
*(data + 20B) = i;
return;
There are 3 multiplications on the L0-L1 path. It should be possible
to only have 2 multiplications on that path.
--
dann at godzilla dot ics dot uci dot edu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30105
[Bug debug/30161] GCC should generate dwarf info about template parameters
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 06:33 --- This seems related to PR 7932. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||7932 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30161
[Bug middle-end/30151] [4.3 Regression] /usr/ccs/bin/ld: Duplicate symbol global destructors keyed to _ZNSt3tr112_GLOBAL__N_16ignoreE
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|/usr/ccs/bin/ld: Duplicate |[4.3 Regression] |symbol global destructors |/usr/ccs/bin/ld: Duplicate |keyed to|symbol global destructors |_ZNSt3tr112_GLOBAL__N_16igno|keyed to |reE|_ZNSt3tr112_GLOBAL__N_16igno ||reE Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30151
[Bug middle-end/30164] New: Gimplifier does not produce valid gimple for global_vectora = CONSTRUCTOR
Testcase (only with the C++ front-end because there is no other way to produce
this kind of internal IR, reduced from g++.dg/init/vector1.C):
typedef signed char v8qi __attribute__ ((vector_size (8)));
int num (void);
v8qi b = (v8qi){ num (), num (), num (), num (), 6, 6, 6, 6 };
--
Summary: Gimplifier does not produce valid gimple for
global_vectora = CONSTRUCTOR
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
OtherBugsDependingO 30142
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30164
[Bug middle-end/30165] New: Gimplifier does not produce valid gimple for (int)real_val
Fortran testcase: res = selected_int_kind (int (t)) end program This is a related issue to PR 30132 which got me started on this whole mess in the first place. -- Summary: Gimplifier does not produce valid gimple for (int)real_val Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org BugsThisDependsOn: 30132 OtherBugsDependingO 30142 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30165
[Bug middle-end/30165] Gimplifier does not produce valid gimple for (int)real_val
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-12 07:20 --- I have a fix for this issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-12 07:20:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30165
[Bug middle-end/30166] New: Gimplifier sometimes does not produce valid gimple for addressable = VIEW_CONVERT_EXPRscalar(a)
Fortran testcase (at -O1 and above because of the conversion of memcpy to VCE): ix = transfer(x,ix) end program I cannot find a C testcase for this issue. -- Summary: Gimplifier sometimes does not produce valid gimple for addressable = VIEW_CONVERT_EXPRscalar(a) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org OtherBugsDependingO 30142 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30166
[Bug middle-end/30167] New: OpenMP can produce invalid gimple (for indirect references)
Fortran Testcase: SUBROUTINE A13( X, XOLD, N, TOL ) !$OMP PARALLEL DO WHILE( TOOBIG 0 ) !$OMP MASTER PRINT *, Iteration , C, TOOBIG=, TOOBIG !$OMP END MASTER ENDDO !$OMP END PARALLEL END SUBROUTINE A12 We get: D.1056 = *(.omp_data_i-toobig); Which is obviously not gimple. Again the testcase in PR 30142 is used to test for this. -- Summary: OpenMP can produce invalid gimple (for indirect references) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org OtherBugsDependingO 30142 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30167
