[Bug fortran/34899] New: Continuation lines with tabnumber not recognized
The following program - which uses a very common extension - is rejected by gfortran. It is accepted by ifort, NAG f95 (!), sunf95, openf95, pgi, absoft. As it is a very common extension, I marked it as reject-valid though the tab makes it non-standard. It is essential that at least for the second and third line a TAB and not spaces are used. PARAMETER (LUMIN=11,LUMAX=20,MAPMAX=256,NPLANEMAX=999) INTEGER NAXIS(0:MAPMAX,LUMIN:LUMAX),NAXIS1(0:MAPMAX,LUMIN:LUMAX), 1NAXIS2(0:MAPMAX,LUMIN:LUMAX),NAXIS3(0:MAPMAX,LUMIN:LUMAX) end From the ifort documentation: In fixed and tab source forms, a continuation line is indicated by one of the following: * For fixed form: Any character (except a zero or blank) in column 6 of a source line * For tab form: Any digit (except zero) after the first tab If this bug is fixed, please also update the *.texi file. -- Summary: Continuation lines with tabnumber not recognized Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #18 from bonzini at gnu dot org 2008-01-21 08:04 --- I agree with Steven. The trimming could be adjusted to not trim register that are mentioned by REG_EQ* notes, but I'm not sure it would be a good idea, either. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-21 08:04:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug fortran/34899] Continuation lines with tabnumber not recognized
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-21 08:45 ---
Real-world test case:
http://www.chara.gsu.edu/~gudehus/fits_library_package.html
Untested:
Index: scanner.c
===
--- scanner.c (revision 131688)
+++ scanner.c (working copy)
@@ -912,12 +912,21 @@
}
if (!openmp_flag)
- for (i = 0; i 5; i++)
- {
- c = next_char ();
- if (c != ' ')
- goto not_continuation;
- }
+ {
+ c = next_char ();
+ if (c == '\t')
+ {
+ c = next_char ();
+ if (c 1 || c 9)
+ goto not_continuation;
+ }
+ else if (c != ' ')
+ goto not_continuation;
+ else
+ for (i = 1; i 5; i++)
+ if ((c = next_char ()) != ' ')
+ goto not_continuation;
+ }
else
for (i = 0; i 5; i++)
{
Index: invoke.texi
===
--- invoke.texi (revision 131688)
+++ invoke.texi (working copy)
@@ -499,10 +499,11 @@
@cindex warnings, tabs
@cindex tabulators
By default, tabs are accepted as whitespace, but tabs are not members
-of the Fortran Character Set. @option{-Wno-tabs} will cause a warning
-to be issued if a tab is encountered. Note, @option{-Wno-tabs} is active
-for @option{-pedantic}, @option{-std=f95}, @option{-std=f2003}, and
[EMAIL PROTECTED]
+of the Fortran Character Set. For continuation lines, a tab followed
+by a digit between 1 and 9 is supported. @option{-Wno-tabs} will cause
+a warning to be issued if a tab is encountered. Note, @option{-Wno-tabs}
+is active for @option{-pedantic}, @option{-std=f95}, @option{-std=f2003},
+and @option{-Wall}.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-01-21 08:45:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899
[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing
--- Comment #31 from rguenth at gcc dot gnu dot org 2008-01-21 09:20 --- Err, did I really close this bug?! I wanted to assign it to myself ... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug tree-optimization/34885] [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
--- Comment #2 from steven at gcc dot gnu dot org 2008-01-21 09:22 --- This is an unhandled expression. A gcc_unreachable() is hit in a switch block. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-21 09:22:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
[Bug c++/33887] [4.1/4.2/4.3 Regression] Reference to bitfield gets wrong value when optimizing
-- 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|REOPENED|ASSIGNED Last reconfirmed|2008-01-14 15:45:40 |2008-01-21 09:20:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33887
[Bug middle-end/34701] ICE in tree-ssa-ccp.c with -fipa-struct-reorg
--- Comment #5 from olga at gcc dot gnu dot org 2008-01-21 09:07 --- Subject: Bug 34701 Author: olga Date: Mon Jan 21 09:07:12 2008 New Revision: 131689 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131689 Log: 2008-01-21 Alon Dayan [EMAIL PROTECTED] Olga Golovanevsky [EMAIL PROTECTED] PR tree-optimization/34701 * gcc.dg/struct/wo_prof_array_field.c: New test. 2008-01-21 Alon Dayan [EMAIL PROTECTED] Olga Golovanevsky [EMAIL PROTECTED] PR tree-optimization/34701 * ipa-struct-reorg.c (gen_size): Fix the malloc parameter calculation when the structure size is not a power of 2. Added: trunk/gcc/testsuite/gcc.dg/struct/wo_prof_array_field.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-struct-reorg.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34701
[Bug other/34900] New: target mips64vrel-elf. Internal compiler error (in reload_cse_simplify_operands, at postreload.c:392) while building libiberty
Hello,
I am experiencing the error below while building gcc 4.2.2 for the mips64vr-elf
target. I have confirmed the same happens with gcc-4.2-20080116.
Versioning:
binutils 2.18
newlib-1.16.0
GCC configured this way:
$ CFLAGS=-O2 $DEPACK_DIR/gcc-4.2.2/configure --target=mips64vrel-elf \
--prefix=$PREFIX_DIR --enable-languages=c,c++ --disable-__cxa_atexit \
--with-gnu-as --with-gnu-ld --with-newlib \
--with-gxx-include-dir=$PREFIX_DIR/mips64vrel-elf/include -v \
21 | tee configure.log
With the same configuration and binutils/newlib, I succeeded building GCC
4.1.2.
I saved all log for configure and make. Please let me know if they may help.
Thanks in advance.
//--
make[4]: Entering directory
`/tmp/build-mips64vrel-elf-20080115/gcc/mips64vrel-elf/mips16/libiberty'
if [ x != x ] [ ! -d pic ]; then \
mkdir pic; \
else true; fi
touch stamp-picdir
CONFIG_FILES=
CONFIG_HEADERS=config.h:/ecostools/src/gcc-4.2.2/libiberty/config.in /bin/sh
./config.status
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing default commands
if [ x != x ]; then \
/tmp/build-mips64vrel-elf-20080115/gcc/./gcc/xgcc
-B/tmp/build-mips64vrel-elf-20080115/gcc/./gcc/ -nostdinc
-B/tmp/build-mips64vrel-elf-20080115/gcc/mips64vrel-elf/newlib/ -isystem
/tmp/build-mips64vrel-elf-20080115/gcc/mips64vrel-elf/newlib/targ-include
-isystem /ecostools/src/gcc-4.2.2/newlib/libc/include
-B/ecostools/mips64vrel-elf-20080115/mips64vrel-elf/bin/
-B/ecostools/mips64vrel-elf-20080115/mips64vrel-elf/lib/ -isystem
/ecostools/mips64vrel-elf-20080115/mips64vrel-elf/include -isystem
/ecostools/mips64vrel-elf-20080115/mips64vrel-elf/sys-include -c
-DHAVE_CONFIG_H -O2 -O2 -mips16 -I.
-I/ecostools/src/gcc-4.2.2/libiberty/../include -W -Wall -pedantic
-Wwrite-strings -Wstrict-prototypes -Wc++-compat
/ecostools/src/gcc-4.2.2/libiberty/regex.c -o pic/regex.o; \
else true; fi
/tmp/build-mips64vrel-elf-20080115/gcc/./gcc/xgcc
-B/tmp/build-mips64vrel-elf-20080115/gcc/./gcc/ -nostdinc
-B/tmp/build-mips64vrel-elf-20080115/gcc/mips64vrel-elf/newlib/ -isystem
/tmp/build-mips64vrel-elf-20080115/gcc/mips64vrel-elf/newlib/targ-include
-isystem /ecostools/src/gcc-4.2.2/newlib/libc/include
-B/ecostools/mips64vrel-elf-20080115/mips64vrel-elf/bin/
-B/ecostools/mips64vrel-elf-20080115/mips64vrel-elf/lib/ -isystem
/ecostools/mips64vrel-elf-20080115/mips64vrel-elf/include -isystem
/ecostools/mips64vrel-elf-20080115/mips64vrel-elf/sys-include -c
-DHAVE_CONFIG_H -O2 -O2 -mips16 -I.
-I/ecostools/src/gcc-4.2.2/libiberty/../include -W -Wall -pedantic
-Wwrite-strings -Wstrict-prototypes -Wc++-compat
/ecostools/src/gcc-4.2.2/libiberty/regex.c -o regex.o
/ecostools/src/gcc-4.2.2/libiberty/regex.c: In function
'byte_re_match_2_internal':
/ecostools/src/gcc-4.2.2/libiberty/regex.c:7481: error: insn does not satisfy
its constraints:
(insn 5298 1670 1672 171 (set (reg:SI 4 $4)
(lo_sum:SI (reg/f:SI 1080)
(symbol_ref:SI (byte_reg_unset_dummy) [flags 0x6] var_decl
0x7fe24fa0 byte_reg_unset_dummy))) 205 {*lowsi_mips16} (nil)
(expr_list:REG_EQUAL (symbol_ref:SI (byte_reg_unset_dummy) [flags 0x6]
var_decl 0x7fe24fa0 byte_reg_unset_dummy)
(nil)))
/ecostools/src/gcc-4.2.2/libiberty/regex.c:7481: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:392
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[4]: *** [regex.o] Error 1
make[4]: Leaving directory
`/tmp/build-mips64vrel-elf-20080115/gcc/mips64vrel-elf/mips16/libiberty'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory
`/tmp/build-mips64vrel-elf-20080115/gcc/mips64vrel-elf/libiberty'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/tmp/build-mips64vrel-elf-20080115/gcc/mips64vrel-elf/libiberty'
make[1]: *** [all-target-libiberty] Error 2
make[1]: Leaving directory `/tmp/build-mips64vrel-elf-20080115/gcc'
make: *** [all] Error 2
--
Summary: target mips64vrel-elf. Internal compiler error (in
reload_cse_simplify_operands, at postreload.c:392) while
building libiberty
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marco at sitek dot it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34900
[Bug c++/34850] [4.3 Regression] Recursive BLOCK tree causes compilation to hang during diagnostics
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-21 09:35 --- Subject: Bug 34850 Author: rguenth Date: Mon Jan 21 09:34:19 2008 New Revision: 131690 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131690 Log: 2008-01-21 Richard Guenther [EMAIL PROTECTED] PR c++/34850 cp/ * error.c (cp_print_error_function): Deal with recursive BLOCK trees. * g++.dg/torture/pr34850.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr34850.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34850
[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel
--- Comment #12 from hubicka at ucw dot cz 2008-01-21 09:54 --- Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel and haydn tester using -O3 -funroll-loops -fpeel-loops -ffast-math -march=native -mtune=native -mfpmath=sse has also started failing at 17th, so this should rule out the extra precision theory :( Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel
--- Comment #11 from hubicka at ucw dot cz 2008-01-21 09:48 --- Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel Hi, also one extra data point, britten tester that uses -O3 -fomit-frame-pointer -ftree-loop-linear -funroll-all-loops -fprefetch-loop-arrays -march=k8 -mfpmath=sse -ffast-math is not getting the faiulre at 32bit runs... Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel
--- Comment #10 from hubicka at ucw dot cz 2008-01-21 09:44 --- Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel --- Comment #8 from hjl dot tools at gmail dot com 2008-01-21 03:09 --- Add -ffloat-store seems to fix the problem. I will verify it. I also found that, but since -ffloat-store changes almost all register allocation, it is dificult to tell if it made just hid the bug or not :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
[Bug c++/34850] [4.3 Regression] Recursive BLOCK tree causes compilation to hang during diagnostics
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-21 09:34 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34850
[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel
--- Comment #9 from hubicka at ucw dot cz 2008-01-21 09:43 --- Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel --- Comment #7 from hjl dot tools at gmail dot com 2008-01-20 16:43 --- Oops. This one Yes, it does make sense. I must've missed it, since I was updating similar cases all around the file. It should not be code correcntess issue, just code quality - we still rely on REG_N_CALLS when asking if register crosses a call, just use frequency to drive decision on profitability of using caller save register. Thanks! I will also look into the two regressions this afternoon unless you beat me. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
[Bug debug/34895] [4.1/4.2/4.3 Regression] CE in force_type_die, at dwarf2out.c:12923
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-01-21 10:15 --- On trunk, ICEs with plain -g. -- 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 Known to fail||4.1.3 4.3.0 Known to work||3.3.6 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2008-01-21 10:15:23 date|| Summary|ICE at dwarf2out.c:13742|[4.1/4.2/4.3 Regression] CE ||in force_type_die, at ||dwarf2out.c:12923 Target Milestone|--- |4.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34895
[Bug c++/34892] [4.3 regression] ICE with ellipsis in default template argument
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P5 Last reconfirmed|-00-00 00:00:00 |2008-01-21 10:10:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34892
[Bug c++/34870] template not instantiated for argument-dependent lookup
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2008-01-21 10:04:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34870
[Bug fortran/34901] New: add kind information to mismatched-types error message
gfortran correctly complains about mismatched types in the code below. However, adding the kinds of the data types would make the message even more informative (see below). $ cat real-real.f90 REAL(4) :: x print *, f(x) CONTAINS FUNCTION f(a) REAL(8) :: a, f a = 3.1415 END FUNCTION END $ gfortran-svn -g -Wall real-real.f90 real-real.f90:2.11: print *, f(x) 1 Error: Type mismatch in argument 'a' at (1); passed REAL to REAL ^^^ $ gfortran-svn -v gcc version 4.3.0 20080116 (experimental) FYI: 4.1/4.2 gave: Error: Type/rank mismatch in argument 'a' at (1) -- Summary: add kind information to mismatched-types error message 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: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34901
[Bug tree-optimization/34885] [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-21 10:36 ---
Err...
# VUSE D.2180_13 { D.2180 }
from_8 = (struct sockaddr *) D.2180
this is not valid gimple.
Reduced testcase:
typedef union {
__const struct sockaddr *__restrict __sockaddr__;
} __CONST_SOCKADDR_ARG __attribute__ ((__transparent_union__));
extern int _pure_socketcall (const struct sockaddr *);
extern int sendto (__CONST_SOCKADDR_ARG __addr);
int send(void)
{
return sendto((void *)0);
}
int sendto(const struct sockaddr *to)
{
return _pure_socketcall(to);
}
The bug occurs during early inlining, when the transparent union is
converted to the formal argument type of _pure_socketcall.
But I'd argue even the initial IL is bogus as it does:
return sendto ({.__sockaddr__=0B});
not passing a middle-end correct value to the call. We gimplify that to
union
{
const struct sockaddr * restrict __sockaddr__;
} D.1555;
D.1555.__sockaddr__ = 0B;
D.1556 = sendto (D.1555);
Obviously the testcase might be invalid (but we don't diagnose this), as
the prototype of sendto doesn't agree with its definition.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
[Bug c/34885] [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-21 10:44 --- That we don't catch this mismatch during gimplifcation and disable inlining for this function is because the C FE doesn't provide DECL_ARGUMENTS for this function! So we fall back to the function types TYPE_ARG_TYPES, and that obviously agree with the type used for the call. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
[Bug fortran/34899] Continuation lines with tabnumber not recognized
--- Comment #2 from burnus at gcc dot gnu dot org 2008-01-21 10:55 --- Actually, this does not work as in scanner.c's load_line the '\t' is changed into 6 spaces. And of cause, if one changes this, e.g., \tPARAMETER is no longer recognized ... + if (c 1 || c 9) And this should be: if (c '1' || c '9') -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34899
[Bug fortran/34901] add kind information to mismatched-types error message
--- Comment #1 from burnus at gcc dot gnu dot org 2008-01-21 11:02 --- Index: interface.c === --- interface.c (revision 131688) +++ interface.c (working copy) @@ -1475,6 +1475,12 @@ compare_parameter (gfc_symbol *formal, g gfc_error (Type mismatch in argument '%s' at %L; passed type(%s) to type(%s), formal-name, actual-where, actual-ts.derived-name, formal-ts.derived-name); + else if (where actual-ts.type != BT_DERIVED + formal-ts.type != BT_DERIVED) + gfc_error (Type mismatch in argument '%s' at %L; passed %s(kind=%d) + to %s(kind=%d), formal-name, actual-where, + gfc_basic_typename (actual-ts.type), actual-ts.kind, + gfc_basic_typename (formal-ts.type), formal-ts.kind); else if (where) gfc_error (Type mismatch in argument '%s' at %L; passed %s to %s, formal-name, actual-where, -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-21 11:02:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34901
[Bug libstdc++/34794] build of gcc 4.2.2 fails on AIX 6.1 / libstdc++-v3/libmath/stubs.c:47
--- Comment #3 from tammer at tammer dot net 2008-01-21 11:14 --- Hello, any news ? Do you need further information / tests ? Bye Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34794
[Bug rtl-optimization/34902] New: Wrong code on -O3
For the attached C/C++ source, illegal code is produced when -O3 is used. One source statement is omitted. This statement is marked by /** ERROR: no code will be generated for the following statement **/ in the source code. The issue can be seen on different platforms, so it seems to be in the RTL optimization part and independent of the backend. I tried on x86 x86_64 and SPARC. Call make ok to get the OK version, make bug to get the buggy one. The driver built around the source prints ok or error respectively. As this is a genereted bison source, it is rather huge, any attempts to make it smaller failed. -- Summary: Wrong code on -O3 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominik dot strasser at onespin-solutions dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
[Bug rtl-optimization/34902] Wrong code on -O3
--- Comment #1 from dominik dot strasser at onespin-solutions dot com 2008-01-21 11:17 --- Created an attachment (id=14986) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14986action=view) tar file with illustrates the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
[Bug c++/34862] [4.3 Regression] operator new placement varient with reference arg not accepted by g++ 4.3
--- Comment #1 from jakub at gcc dot gnu dot org 2008-01-21 11:20 --- Apparently caused by my PR33025 fix, will look into this. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-21 11:20:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug c/34885] [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
--- Comment #5 from steven at gcc dot gnu dot org 2008-01-21 11:52 --- I thought inlining is disabled for mismatching function prototype/definition? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
[Bug c/34885] [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
--- Comment #6 from rguenther at suse dot de 2008-01-21 12:03 --- Subject: Re: [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574 On Mon, 21 Jan 2008, steven at gcc dot gnu dot org wrote: --- Comment #5 from steven at gcc dot gnu dot org 2008-01-21 11:52 --- I thought inlining is disabled for mismatching function prototype/definition? Yes, but as we are not gimplifying unit-at-a-time the call actually matches the types of the prototype (and no DECL_ARGUMENTS are yet there to verify against). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
[Bug rtl-optimization/34902] Wrong code on -O3
--- Comment #2 from manu at gcc dot gnu dot org 2008-01-21 12:12 --- Could you try to compile it by adding -Wstrict-overflow=5 as the last warning flag (after -Wall)? Independently, could you try to compile it by adding the -fwrapv flag? -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
[Bug rtl-optimization/34902] Wrong code on -O3
--- Comment #3 from dominik dot strasser at onespin-solutions dot com 2008-01-21 12:17 --- -Wstrict-overflow=5 doesn't seem to be available in 4.1.2 -fwrapv didn't make a difference. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
[Bug c++/24314] Extra template in partial specialization is compiled successfuly.
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-01-21 12:22 --- *** Bug 34834 has been marked as a duplicate of this bug. *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||sylvain dot pion at sophia ||dot inria dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24314
[Bug c++/34834] Accepts invalid code for partial specializations.
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-01-21 12:22 --- *** This bug has been marked as a duplicate of 24314 *** -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34834
[Bug rtl-optimization/34628] [4.2/4.3 Regression] problems with inlining on ARM
--- Comment #13 from tbm at cyrius dot com 2008-01-21 12:31 --- (In reply to comment #11) Created an attachment (id=14907) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14907action=view) [edit] Lightly tested fix. I'll give it a whirl on IA-64 but it would be nice to test it on ARM too. Eric, was your testing successful? I'll give it a go on ARM now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
[Bug rtl-optimization/34902] Wrong code on -O3
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-01-21 12:44 --- Does -fno-strict-aliasing? Does adding that option with -O3 does that fix the issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #2 from jakub at gcc dot gnu dot org 2008-01-21 12:45 ---
Actually, only the diagnostics is a regression introduced by PR33025 fix.
Before that (but after PR29286 fix) at -O1 and higher cc1plus ICEd in
gimplify_expr and at -O0 it silently miscompiled e.g.:
typedef __SIZE_TYPE__ size_t;
extern C void abort ();
struct T
{
void *operator new (size_t, char *);
T () { i[0] = 1; i[1] = 2; }
int i[2];
};
void *T::operator new (size_t size, char *p)
{
void *o = (void *) p;
p += size;
return o;
}
T *f (char *x)
{
return new (x) T ();
}
int main ()
{
char buf[10 * sizeof (T)] __attribute__((aligned (__alignof (T;
char *p = buf;
f (p);
if (p != buf + sizeof (T))
abort ();
}
Here get_temp_regvar created a temporary for the placement expr and that
temporary was passed by reference to operator new. That means only the
temporary
was modified, not the user variable.
Do we still need avoid_placement_new_aliasing stuff now that we have PR33407
fix in? If yes, we either need to do replacement of the original expression
with
get_target_expr after build_new_method_call/build_operator_new_call (and
replace it both in the newly created argument list, in placement and
placement_expr, and only if the pointer was passed by value, not by reference),
or somehow undo this target_expr if a reference is needed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||ian at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug c/34885] [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-01-21 12:58 ---
So, either the source is invalid and the C FE should diagnose it, or we can
'work around' this (and similarly bogus) issues by using VIEW_CONVERT_EXPR
to make the IL valid again.
Ha, and we do. With -pedantic-errors:
psc.3.i: At top level:
psc.3.i:11: error: function types not truly compatible in ISO C
the code in c-typeck.c:composite_type
/* Given wait (union {union wait *u; int *i} *)
and wait (union wait *),
prefer union wait * as type of parm. */
if (TREE_CODE (TREE_VALUE (p1)) == UNION_TYPE
TREE_VALUE (p1) != TREE_VALUE (p2))
{
...
and now you think the middle-end should simply deal with it? Bah!
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|ice-on-valid-code |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #19 from zadeck at naturalbridge dot com 2008-01-21 13:02 --- Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90 bonzini at gnu dot org wrote: --- Comment #18 from bonzini at gnu dot org 2008-01-21 08:04 --- I agree with Steven. The trimming could be adjusted to not trim register that are mentioned by REG_EQ* notes, but I'm not sure it would be a good idea, either. I am testing a patch that add eq_notes to the lr problem if you specify DF_EQ_NOTES. If you and steven still want me to abandon this, i will, but in my mind, it seems that if the pass wants chains built with eq_notes, then the rest of the df information should match this decision. Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug rtl-optimization/34902] Wrong code on -O3
--- Comment #5 from dominik dot strasser at onespin-solutions dot com 2008-01-21 13:07 --- Bingo -fno-strict-aliasing does the trick. But what shall I do ? This is a generated Bison parser. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
[Bug c/34885] [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
-- 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|2008-01-21 09:22:52 |2008-01-21 13:15:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #20 from bonzini at gnu dot org 2008-01-21 13:21 --- Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90 I am testing a patch that add eq_notes to the lr problem if you specify DF_EQ_NOTES. If you and steven still want me to abandon this, i will, but in my mind, it seems that if the pass wants chains built with eq_notes, then the rest of the df information should match this decision. Chains is one thing, liveness is another. EQ notes are there as reminders of useful information, I don't want them to affect register allocation (via liveness) if the information was not used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug rtl-optimization/34902] Wrong code on -O3
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-21 13:22 --- If I remember correctly this was a bug with bison itself. What version of bison are you using? I suggest to simply use -fno-strict-aliasing for this generated file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #21 from zadeck at naturalbridge dot com 2008-01-21 13:25 --- Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90 bonzini at gnu dot org wrote: --- Comment #20 from bonzini at gnu dot org 2008-01-21 13:21 --- Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90 I am testing a patch that add eq_notes to the lr problem if you specify DF_EQ_NOTES. If you and steven still want me to abandon this, i will, but in my mind, it seems that if the pass wants chains built with eq_notes, then the rest of the df information should match this decision. Chains is one thing, liveness is another. EQ notes are there as reminders of useful information, I don't want them to affect register allocation (via liveness) if the information was not used. I understand that, that is why if the pass does not specify DF_EQ_NOTES, the lr (and the rest of the info) stays as it is now. But if you are building chains out of them, then you are treating them as live anyway. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #39 from olga at gcc dot gnu dot org 2008-01-21 13:33 --- (In reply to comment #38) With patch form comments #11 and #31, the executable for gcc.dg/struct/wo_prof_mult_field_peeling.c segfault with -m64. I have used the 32 bit mode for -fprofile-generate, run the executable, and use -m64 for -fprofile-use. wo_prof_mult_field_peeling_db.c is the code from comment #34. Yes... The assembly for wo_prof_mult_field_peeling.c looks unrolled. But I have number of question to you. Why are you running wo_prof_mult_field_peeling.c with profiling? At least, it was not intended to be executed this way. If it is, then it is a bug in struct-reorg.exp. The other question is whether the failing tests that should run *with* profiling, like w_prof_gloval_var.c and w_prof_local_var.c, fail after compilation with -fprofile-generate or after second compilation with -fprofile-use. Thanks a lot for debugging, Olga -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34856] [4.3 Regression] ICE with some constant vectors
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-01-21 13:42 ---
Confirmed. In the latter case we const-propped the initializer into the
V_C_E:
VIEW_CONVERT_EXPRvector signed char({(unsigned int) g[16]})
which is of course neither CONSTANT_CLASS_P nor a gimple lvalue (but it is
is_gimple_min_invariant, which is why we propagate it in the first place):
/* Vector constant constructors are gimple invariant. */
case CONSTRUCTOR:
if (TREE_TYPE (t) TREE_CODE (TREE_TYPE (t)) == VECTOR_TYPE)
return TREE_CONSTANT (t);
else
return false;
The point is, that we do allow V_C_E expressions on rvalues, so the
verification is simply bogus.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
[Bug rtl-optimization/34902] Wrong code on -O3
--- Comment #7 from dominik dot strasser at onespin-solutions dot com 2008-01-21 13:45 --- This is bison 2.0. The latest version is 2.3. If haven't found anything in the ChangeLog which sounds like there was a bug fix in this area. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34902
[Bug middle-end/34856] [4.3 Regression] ICE with some constant vectors
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-01-21 13:54 --- And for_each_index does not handle CONSTRUCTOR. Then, we ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574 because that obviously also does not handle CONSTRUCTOR either. _Then_, at -O2, we ICE in simplify_immed_subreg (x86_64 -m32 -msse) #1 0x0085ed6b in simplify_immed_subreg (outermode=V16QImode, op=0x2ae82bd7b6b0, innermode=V4SImode, byte=0) at /space/rguenther/src/svn/trunk/gcc/simplify-rtx.c:4761 4761 gcc_unreachable (); (gdb) call debug_rtx (op) (const_vector:V4SI [ (const:SI (plus:SI (symbol_ref:SI (g) [flags 0x40] var_decl 0x2ae82c6450a0 g) (const_int 32 [0x20]))) (const_int 0 [0x0]) (const_int 0 [0x0]) (const_int 0 [0x0]) ]) as we don't handle a const:SI wrapped first vector element. I'm going to fix the non-rtl cases. -- 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|2008-01-18 20:44:51 |2008-01-21 13:54:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #40 from dominiq at lps dot ens dot fr 2008-01-21 14:09 --- Why are you running wo_prof_mult_field_peeling.c with profiling? My best guess is because I have reused some previous command line(s) with it (from gcc.dg/struct/w_prof_global_array.c for instance) without thinking about it. Anyway, I have run all the tests in gcc.dg/struct failing with -m64 with -O3 -fipa-struct-reorg -fwhole-program -combine -fipa-type-escape -m64 and they all crash with Segmentation fault. The backtrace for gcc.dg/struct/wo_prof_mult_field_peeling.c is: Process: a.out [41283] Path:a.out Identifier: a.out Version: ??? (???) Code Type: X86-64 (Native) Parent Process: tcsh [11101] Date/Time: 2008-01-21 15:03:26.935 +0100 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00200a70 Crashed Thread: 0 Thread 0 Crashed: 0 a.out 0x00010f40 main + 64 1 a.out 0x00010ed4 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x00200a70 rbx: 0x rcx: 0x rdx: 0x rdi: 0x0001002fc095 rsi: 0x rbp: 0x7fff5fbfec10 rsp: 0x7fff5fbfec10 r8: 0x0001002fe01a r9: 0x0100 r10: 0x0301 r11: 0x7fff8416e474 r12: 0x r13: 0x r14: 0x r15: 0x rip: 0x00010f40 rfl: 0x00010246 cr2: 0x00200a70 Binary Images: 0x1 -0x10ff7 +a.out ??? (???) /Volumes/MacBook/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out 0x13000 -0x1000c9fef +libgfortran.3.dylib ??? (???) ac0635c6511429acc90b895479c2cbb0 /opt/gcc/gcc4.3w/lib/x86_64/libgfortran.3.dylib 0x10010d000 -0x100120ff1 +libgcc_s.1.dylib ??? (???) e9505452e93d052d01993982f18fa20a /opt/gcc/gcc4.3w/lib/libgcc_s.1.dylib 0x7fff5fc0 - 0x7fff5fc2e3a3 dyld 95.3 (???) cd99d065ba4917450dca6958a854c594 /usr/lib/dyld 0x7fff819a9000 - 0x7fff819b5ff1 libgcc_s.1.dylib ??? (???) 6fc905606335f261db4da9529c7e2711 /usr/lib/libgcc_s.1.dylib 0x7fff83fcd000 - 0x7fff83fc libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x7fff8416c000 - 0x7fff842ebfeb libSystem.B.dylib ??? (???) a9297f52cb1431e26cd3ffd4b9ca7615 /usr/lib/libSystem.B.dylib 0x7fe0 - 0x7fe01780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib for gcc.dg/struct/wo_prof_two_strs.c Process: a.out [41292] Path:a.out Identifier: a.out Version: ??? (???) Code Type: X86-64 (Native) Parent Process: tcsh [11101] Date/Time: 2008-01-21 15:04:45.522 +0100 OS Version: Mac OS X 10.5.1 (9B18) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x00809600 Crashed Thread: 0 Thread 0 Crashed: 0 a.out 0x00010ed0 main + 256 1 a.out 0x00010da4 start + 52 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0080d600 rbx: 0x0fa0 rcx: 0x000100ff80d6 rdx: 0x rdi: 0x00809600 rsi: 0x03e8 rbp: 0x7fff5fbfec10 rsp: 0x7fff5fbfebf0 r8: 0x034d2346 r9: 0x r10: 0x00012140 r11: 0x7fff8416e474 r12: 0x00010080a600 r13: 0x0080c600 r14: 0x r15: 0x rip: 0x00010ed0 rfl: 0x00010246 cr2: 0x00809600 Binary Images: 0x1 -0x10fff +a.out ??? (???) /Volumes/MacBook/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out 0x13000 -0x1000c9fef +libgfortran.3.dylib ??? (???) ac0635c6511429acc90b895479c2cbb0 /opt/gcc/gcc4.3w/lib/x86_64/libgfortran.3.dylib 0x10010d000 -0x100120ff1 +libgcc_s.1.dylib ??? (???) e9505452e93d052d01993982f18fa20a /opt/gcc/gcc4.3w/lib/libgcc_s.1.dylib 0x7fff5fc0 - 0x7fff5fc2e3a3 dyld 95.3 (???) cd99d065ba4917450dca6958a854c594 /usr/lib/dyld 0x7fff819a9000 - 0x7fff819b5ff1 libgcc_s.1.dylib ??? (???) 6fc905606335f261db4da9529c7e2711 /usr/lib/libgcc_s.1.dylib 0x7fff83fcd000 - 0x7fff83fc libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x7fff8416c000 - 0x7fff842ebfeb libSystem.B.dylib ??? (???) a9297f52cb1431e26cd3ffd4b9ca7615 /usr/lib/libSystem.B.dylib 0x7fe0 - 0x7fe01780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib and so on (I can give similar ones for the other cases). Note that if I remove '-fipa-type-escape' the segfaults disappear (with unpatched rev. 131689). --
[Bug c++/34862] [4.3 Regression] operator new placement variant with reference arg not accepted by g++ 4.3
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-21 14:15 ---
To answer my question, new16.C fails if the build_new_1 setting of
placement_expr and both calls to avoid_placement_new_aliasing are commented
out. I believe PR33407 is meant to handle this, unfortunately there is nothing
that prevents coalescing DECL_NO_TBAA_P variables with non-DECL_NO_TBAA_P ones.
At *.cleanup_cfg2 time we have in the inner loop:
lD.2031_7 = (intD.2 *) pD.2025_6(D);
*lD.2031_7 ={v} 0;
D.2058_13 = pD.2025_6(D);
D.2036_8 = D.2058_13;
fD.2029_9 = (long intD.5 *) D.2036_8;
*fD.2029_9 ={v} -1;
iD.2030_10 = iD.2030_2 + 1;
where D.2058 is DECL_NO_TBAA_P. But:
Try : D.2058_13(P13) p_6(D)(P6) : Incompatible types. No coalesce.
Try : D.2036_8(P8) D.2058_13(P13) -- P8 D.2036
Coalesced D.2058_13 to D.2036_8
already at *.copyrename1 time and DECL_NO_TBAA_P is lost. If DECL_NO_TBAA_P
decls are lost this easily, I guess PR33407 was fixed just by luck that in that
case it is not optimized out away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34862
[Bug rtl-optimization/34628] [4.2/4.3 Regression] problems with inlining on ARM
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-01-21 14:25 --- Eric, was your testing successful? Yes, everything is clean on the IA-64. I'll give it a go on ARM now. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
[Bug c/34885] [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-01-21 14:26 --- Subject: Bug 34885 Author: rguenth Date: Mon Jan 21 14:25:46 2008 New Revision: 131694 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131694 Log: 2008-01-21 Richard Guenther [EMAIL PROTECTED] PR c/34885 * tree-inline.c (setup_one_parameter): Deal with mismatched types using a VIEW_CONVERT_EXPR. * gcc.c-torture/compile/pr34885.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr34885.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
[Bug c/34885] [4.3 Regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:574
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-01-21 14:26 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34885
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #23 from steven at gcc dot gnu dot org 2008-01-21 14:38 --- The similar condition for reaching definitions is not liveness, but absence of uses. To trim reaching definitions, one should really be looking at the last reachable use of a definition, and trim from there. Just to clarify, this trimming still changes the result of the reaching definitions problem, but should not change the resulting DEF-USE chains. For the reaching definitions problem itself, I don't see any way to trim it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #24 from dominiq at lps dot ens dot fr 2008-01-21 14:39 --- Side note for the record: the polyhedron test mdbx.f90 also fails in 32 bit mode with rev. 131689 on i686-apple-darwin9. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #25 from rguenth at gcc dot gnu dot org 2008-01-21 14:40 --- Can we revert the offending patch and revisit this issue during stage1 please? Thanks. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug c++/34886] Strangeness of name lookup in template function
--- Comment #3 from rvovsd at mail dot ru 2008-01-21 14:43 --- This case is similar to the bug 31047 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31047). There Andrew Pinski wrote (comment 4): 14.6.4.2/1 says this is invalid code. For a function call that depends on a template parameter, if the function is an unqualified-id but not a template-id, the candiate functions are found using the usual lookup rules (3.4.1, 3.4.2) except that: Paraphasing since I don't want to type it all in * non argument dependent lookup (3.4.1: template definition context * argument dependent lookup (3.4.2): template definition context and template instation context This case is argument dependent lookup, therefore should used both contexts - definition and instantiation. Point of instantiation sel(T* a) with T = void - after void f(void*) and before int main(). Thus should be visible both f(void*) and f(Y*), whether not so? Why gcc does not see void f (void *)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34886
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #26 from bonzini at gnu dot org 2008-01-21 14:54 --- Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90 Agreed. I think we'd better revert the patch now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug middle-end/34483] wo_prof_two_strs.c:56: internal compiler error: in find_new_var_of_type, at ipa-struct-reorg.c:605
--- Comment #41 from dominiq at lps dot ens dot fr 2008-01-21 14:54 --- Sorry I missed the second question: The other question is whether the failing tests that should run *with* profiling, like w_prof_gloval_var.c and w_prof_local_var.c, fail after compilation with -fprofile-generate or after second compilation with -fprofile-use. They failed with -fprofile-generate (BTW they fail without -fprofile-*). What I said in comment #38, is that I profiled the test(s) in 32 bit mode then compiled with -profile-use -m64 (I do not expect that to be right, but gcc did not complain about that). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34483
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #22 from stevenb dot gcc at gmail dot com 2008-01-21 14:29 --- Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90 On 21 Jan 2008 13:25:23 -, zadeck at naturalbridge dot com gcc- I understand that, that is why if the pass does not specify DF_EQ_NOTES, the lr (and the rest of the info) stays as it is now. But if you are building chains out of them, then you are treating them as live anyway. This is not really true. You are treating the registers as reaching, i.e. even though the register is not live at the point of the REG_EQ* note, it _could_ be live holding the value expected for the REG_EQ* note. This difference between live registers and reaching definitions is also why I feel so uncomfortable about the RD patch. After trimming, DEFs that reach a certain point in the program don't show up in the reaching definitions anymore. You've already found one example how this can be confusing (the loop IV problem). It also breaks my new const/copy prop pass, which expects definitions to reach points where the register of the reaching def is not live. What is confusing about all this, is that in GCC there is nothing to prevent you from inserting a new SET of a register between a previous set of the register and a use in an REG_EQ* note, if the register is dead at the point of the REG_EQ* note. E.g. it is perfectly OK to have a situation like this: (insn 1 (set (reg1) (...))) (insn 2 (...) REG_DEAD (reg1)) (insn 3 (...) REG_EQUAL (... ((reg1) ...))) and nothing in the compiler will object if you would insert a new insn like so: (insn 1 (set (reg1) (...))) (insn 2 (...) REG_DEAD (reg1)) (insn 4 (set (reg1) (...))) (insn 3 (...) REG_EQUAL (... ((reg1) ...))) even though this would probably result in wrong code. The way GCC avoids this kind of situation, is by never re-using registers this way, unless the new definition sets reg1 to the same value (gcse PRE does this, for example). The effect of including REG_* notes in the LR and LIVE problems would be to extend the live ranges of pseudos into regions where they are not actually live. What it comes down to, is that it seems that liveness is not a good condition to trim reaching definitions. Trimming LIVE with LR makes sense because the result of the problem does not change, and the nature of the problems are the same (i.e. compute two meanings of liveness for registers). Live registers and reaching definitions, on the other hand, are dissimilar problems. For LIVE, the effect of trimming is to not compute partial availability in regions where a register is not live. The similar condition for reaching definitions is not liveness, but absence of uses. To trim reaching definitions, one should really be looking at the last reachable use of a definition, and trim from there. I don't know what problem computes the last use of a register, but it may well be a problem that is equivalent to the LR problem, but considering *all* uses including REG_EQ* uses, instead of only real uses. But I haven't thought about this much yet, I must admit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug libstdc++/33486] parallel v3: functions not in right namespace
--- Comment #3 from singler at gcc dot gnu dot org 2008-01-21 15:14 --- So is this a bug in the library or in the definition/implementation of namespace association? The documentation on namespace association even mentions argument-dependent lookup. http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33486
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #3 from jakub at gcc dot gnu dot org 2008-01-21 15:14 --- Reproducible even with x86_64-linux - i686-darwin9 cross, at -Os as well as -O2 -mno-accumulate-outgoing-args. The difference between i686-linux and i686-darwin9 that matters here is that darwin defines STACK_BOUNDARY to 128, while linux to 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel
--- Comment #13 from hjl dot tools at gmail dot com 2008-01-21 15:14 --- I tried -mpc64. It also works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
[Bug fortran/34901] add kind information to mismatched-types error message
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-01-21 15:17 --- In reply to comment #1: Bootstrapped and regression tested on i686-pc-linux-gnu. No additional regressions besides shown in [1]. [1] http://gcc.gnu.org/ml/gcc-testresults/2008-01/msg00966.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34901
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #4 from jakub at gcc dot gnu dot org 2008-01-21 15:22 ---
Shorter testcase:
void foo (int, ...);
__attribute__ ((vector_size (16))) int v;
void
bar (void)
{
foo (1, v);
}
with -O2 -mno-accumulate-outgoing-args -m32 or -Os -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug c/34903] New: -Os code size regression
I can't build the embedded application (U-Boot firmware) using the GCC 4.2.2 powerpc-linux cross because resultant code doesn't fit into the reserved space anymore. GCC 4.0.0 powerpc cross build it OK. Investigation showed that the code size generated by the GCC 4.2.2 is about 6% bigger as produced by GCC 4.0.0, as reported by 'size': gcc 4.2.2: textdata bss dec hex filename 2696 601536429210c4 interrupts.o gcc 4.0.0: textdata bss dec hex filename 2424 8815364048 fd0 interrupts.o In both cases, same compilation options are used: ppc-linux-gcc -g -Os -fPIC -ffixed-r14 -meabi -fno-strict-aliasing -D__KERNEL__ -DTEXT_BASE=0xfffc -I/work/psl/tmp/u-boot/include -fno-builtin -ffreestanding -nostdinc -isystem /opt/eldk-4.2-01-08/usr/bin/../lib/gcc/powerpc-linux/4.2.2/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_4xx -ffixed-r2 -ffixed-r29 -mstring -msoft-float -Wa,-m440 -mcpu=440 -DCONFIG_440=1 -Wall -Wstrict-prototypes -c -o interrupts.o interrupts.c Removing -ffixed doesn't change the generated assembler code for 4.2.2 Test case and generated outputs will follow. -- Summary: -Os code size regression Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sposelenov at emcraft dot com GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
[Bug c/34903] -Os code size regression
--- Comment #1 from sposelenov at emcraft dot com 2008-01-21 15:36 --- Created an attachment (id=14987) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14987action=view) Preprocessed output, GCC 4.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
--- Comment #27 from zadeck at naturalbridge dot com 2008-01-21 15:36 --- Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90 bonzini at gnu dot org wrote: --- Comment #26 from bonzini at gnu dot org 2008-01-21 14:54 --- Subject: Re: [4.3 Regression] gfortran.dg/array_constructor_9.f90 Agreed. I think we'd better revert the patch now. i give. i will prepare a revert this afternoon. i need to go run some errands now. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug c/34903] -Os code size regression
--- Comment #2 from sposelenov at emcraft dot com 2008-01-21 15:37 --- Created an attachment (id=14988) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14988action=view) Resulted assembler,GCC 4.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #5 from jakub at gcc dot gnu dot org 2008-01-21 15:38 ---
And varargs aren't even needed:
typedef __attribute__ ((vector_size (16))) int V;
void foo (int, V, V, V, V);
V v;
void
bar (void)
{
foo (1, v, v, v, v);
}
The regression has been caused by
http://gcc.gnu.org/viewcvs?root=gccview=revrev=12
pad_to_arg_alignment in this case doesn't increase alignment_pad:
if (boundary PARM_BOUNDARY boundary STACK_BOUNDARY)
alignment_pad-constant = offset_ptr-constant - save_constant;
because boundary in this case is equal to STACK_BOUNDARY.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||geoffk at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug c/34903] -Os code size regression
--- Comment #3 from sposelenov at emcraft dot com 2008-01-21 15:41 --- Created an attachment (id=14989) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14989action=view) preprocessed output, GCC 4.0.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
[Bug c/34903] -Os code size regression
--- Comment #4 from sposelenov at emcraft dot com 2008-01-21 15:42 --- Created an attachment (id=14990) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14990action=view) resulted assmbelr, GCC 4.0.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
[Bug target/34904] New: -march=native doesn't work with multiple input files
bash-3.2$ /usr/gcc-4.3/bin/gcc -m32 -c y.i z.i -march=core2 -mfpmath=sse bash-3.2$ /usr/gcc-4.3/bin/gcc -m32 -c y.i z.i -march=native -mfpmath=sse z.i:1: warning: SSE instruction set disabled, using 387 arithmetics The problem is gcc driver never passed the proper -march=xxx to COLLECT_GCC_OPTIONS. -- Summary: -march=native doesn't work with multiple input files Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34904
[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel
--- Comment #14 from hjl dot tools at gmail dot com 2008-01-21 15:51 --- (In reply to comment #12) Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel and haydn tester using -O3 -funroll-loops -fpeel-loops -ffast-math -march=native -mtune=native -mfpmath=sse has also started failing at 17th, so this should rule out the extra precision theory :( Did you compile input files with the same command line? -march=native doesn't work with more than one input file. See bug 34904. Only the first file will use SSE math. -- hjl dot tools at gmail dot com changed: What|Removed |Added BugsThisDependsOn||34904 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
[Bug target/34903] -Os code size regression
--- Comment #5 from dje at gcc dot gnu dot org 2008-01-21 15:54 --- The regression is due to a wrong-code bug fix. To reduce the code size, the prologue and epilogue need to emit lwm/stwm for two ranges of registers, which does not correspond to a standard PowerPC ABI. -- dje at gcc dot gnu dot org changed: What|Removed |Added CC||dje at gcc dot gnu dot org Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-21 15:54:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
[Bug tree-optimization/18501] [4.1/4.2/4.3 Regression] Missing 'used unintialized' warning (CCP)
--- Comment #15 from manu at gcc dot gnu dot org 2008-01-21 16:01 --- This is CCP related. (See Problem 2: CCP assumes a value for uninitialized variables in http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings) -- manu at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 Regression]|[4.1/4.2/4.3 Regression] |Missing 'used unintialized' |Missing 'used unintialized' |warning |warning (CCP) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
[Bug c/34903] -Os code size regression
--- Comment #6 from sposelenov at emcraft dot com 2008-01-21 16:08 --- (In reply to comment #5) The regression is due to a wrong-code bug fix. To reduce the code size, the prologue and epilogue need to emit lwm/stwm for two ranges of registers, which does not correspond to a standard PowerPC ABI. Thanks, understood. Would you please specify the bug # for this fix? I can't find any useful. -- sposelenov at emcraft dot com changed: What|Removed |Added Severity|enhancement |normal Component|target |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
[Bug tree-optimization/34590] GCC-4.3.0-20071221 SEGV's building Bzip2 1.0.4 decompress.c with -ftree-parallelize-loops=4
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-12-26 14:21:21 |2008-01-21 16:13:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34590
[Bug middle-end/34856] [4.3 Regression] ICE with some constant vectors
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-01-21 16:22 --- Subject: Bug 34856 Author: rguenth Date: Mon Jan 21 16:21:45 2008 New Revision: 131696 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131696 Log: 2008-01-21 Richard Guenther [EMAIL PROTECTED] PR middle-end/34856 * tree-cfg.c (verify_expr): Allow all invariant expressions instead of just constant class ones as reference argument. * tree-ssa-loop-im.c (for_each_index): Handle CONSTRUCTOR like any other constant. * tree-ssa-sccvn.c (copy_reference_ops_from_ref): Likewise. * gcc.c-torture/compile/pr34856.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr34856.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-ssa-loop-im.c trunk/gcc/tree-ssa-sccvn.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
[Bug rtl-optimization/34856] [4.3 Regression] ICE with some constant vectors
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-21 16:24 --- tree parts fixed. Eric, can you look into the RTL parts? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Component|middle-end |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856
[Bug c++/29469] [DR 224] [4.1/4.2/4.3 Regression] error: non-template 'pair' used as template
--- Comment #9 from jsm28 at gcc dot gnu dot org 2008-01-21 16:30 --- Bugs waiting for the committee should not be release-critical; we can restore this to P3 and reconsider the priority when unsuspending. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug c++/29607] [DR 224] [4.1/4.2/4.3 Regression] dependent name with base classes
--- Comment #13 from jsm28 at gcc dot gnu dot org 2008-01-21 16:32 --- Bugs waiting for the committee should not be release-critical; we can restore this to P3 and reconsider the priority when unsuspending. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29607
[Bug middle-end/34884] [4.3 Regression] gfortran.dg/array_constructor_9.f90
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34884
[Bug c++/34846] [4.3 regression] ICE on STL container iterator copy
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34846
[Bug middle-end/34852] [4.3 Regression] Revision 131576 miscompiled 178.galgel
--- Comment #15 from hubicka at ucw dot cz 2008-01-21 16:42 --- Subject: Re: [4.3 Regression] Revision 131576 miscompiled 178.galgel I tried -mpc64. It also works. I would declare this a proof that it is extra preccision issue and simply update testers to use -mpc64. It is what most of other compilers do anyway and thus we would get more comparable scores. Thanks a lot for testing it (I've scheduled same test for tonight, but you've beaten me. I still will try if it works for -mfpmath=sse case too) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34852
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #6 from geoffk at gcc dot gnu dot org 2008-01-21 16:43 --- I suspect that the patch changed bad code generation into a crash, which is not a regression... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug tree-optimization/34590] GCC-4.3.0-20071221 SEGV's building Bzip2 1.0.4 decompress.c with -ftree-parallelize-loops=4
--- Comment #5 from rakdver at gcc dot gnu dot org 2008-01-21 16:43 --- I cannot reproduce this with the current mainline (rev 131696), neither with the original testcase nor the reduced one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34590
[Bug middle-end/34905] New: valgrind error indication from testsuite typeck.c:comptypes
FAIL: g++.dg/conversion/simd1.C (test for excess errors) Excess errors: ==18116== Conditional jump or move depends on uninitialised value(s) ==18116==at 0x80CFD96: comptypes (typeck.c:1107) ==18116==by 0x8122A01: vector_types_convertible_p (c-common.c:1196) ==18116==by 0x80DA8BA: convert_for_assignment (typeck.c:6349) ==18116==by 0x80DAEAE: convert_for_initialization (typeck.c:6540) ==18116==by 0x80DB6A2: check_return_expr (typeck.c:6832) ==18116==by 0x80EF109: finish_return_stmt (semantics.c:787) ==18116==by 0x80B8AE6: cp_parser_jump_statement (parser.c:7460) ==18116==by 0x80B7B3D: cp_parser_statement (parser.c:6649) ==18116==by 0x80B804D: cp_parser_statement_seq_opt (parser.c:6931) ==18116==by 0x80B7F84: cp_parser_compound_statement (parser.c:6888) ==18116==by 0x80BFCBA: cp_parser_function_body (parser.c:13765) ==18116==by 0x80BFCE3: cp_parser_ctor_initializer_opt_and_function_body (parser.c:13782) -- Summary: valgrind error indication from testsuite typeck.c:comptypes Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at pardus dot org dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34905
[Bug middle-end/34906] New: valgrind error indication from testsuite gimplify.c: gimplify_asm_expr
FAIL: g++.dg/ext/asm3.C (test for excess errors) Excess errors: ==25921== Conditional jump or move depends on uninitialised value(s) ==25921==at 0x8292529: gimplify_asm_expr (gimplify.c:4285) ==25921==by 0x82952A7: gimplify_expr (gimplify.c:5904) ==25921==by 0x8292FD7: gimplify_stmt (gimplify.c:4644) ==25921==by 0x8292FEA: gimplify_to_stmt_list (gimplify.c:4652) ==25921==by 0x8292A7C: gimplify_cleanup_point_expr (gimplify.c:4462) ==25921==by 0x82952ED: gimplify_expr (gimplify.c:5915) ==25921==by 0x8292FD7: gimplify_stmt (gimplify.c:4644) ==25921==by 0x8292128: gimplify_statement_list (gimplify.c:4094) ==25921==by 0x829544D: gimplify_expr (gimplify.c:5957) ==25921==by 0x8292FD7: gimplify_stmt (gimplify.c:4644) ==25921==by 0x8292FEA: gimplify_to_stmt_list (gimplify.c:4652) ==25921==by 0x828C85C: gimplify_bind_expr (gimplify.c:1103) ==25921==· ==25921== Conditional jump or move depends on uninitialised value(s) ==25921==at 0x829258E: gimplify_asm_expr (gimplify.c:4294) ==25921==by 0x82952A7: gimplify_expr (gimplify.c:5904) ==25921==by 0x8292FD7: gimplify_stmt (gimplify.c:4644) ==25921==by 0x8292FEA: gimplify_to_stmt_list (gimplify.c:4652) ==25921==by 0x8292A7C: gimplify_cleanup_point_expr (gimplify.c:4462) ==25921==by 0x82952ED: gimplify_expr (gimplify.c:5915) ==25921==by 0x8292FD7: gimplify_stmt (gimplify.c:4644) ==25921==by 0x8292128: gimplify_statement_list (gimplify.c:4094) ==25921==by 0x829544D: gimplify_expr (gimplify.c:5957) ==25921==by 0x8292FD7: gimplify_stmt (gimplify.c:4644) ==25921==by 0x8292FEA: gimplify_to_stmt_list (gimplify.c:4652) ==25921==by 0x828C85C: gimplify_bind_expr (gimplify.c:1103) -- Summary: valgrind error indication from testsuite gimplify.c: gimplify_asm_expr Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ismail at pardus dot org dot tr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34906
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
-- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
[Bug target/34903] -Os code size regression
--- Comment #7 from dje at gcc dot gnu dot org 2008-01-21 16:37 --- First, please stop changing the categorization of this bug. The patch which changed this behavior is http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00276.html -- dje at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34903
[Bug tree-optimization/24609] [4.0/4.1/4.2/4.3 regression] Same value duplicated in two different registers
--- Comment #16 from steven at gcc dot gnu dot org 2008-01-21 17:10 --- It's been half a year since anyone said anything about this bug... Ian, pinski asked you a question. Thoughts? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24609
[Bug middle-end/34905] valgrind error indication from testsuite typeck.c:comptypes
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-21 17:11 --- Used svn revision 131650. -- ismail at pardus dot org dot tr changed: What|Removed |Added GCC target triplet||i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34905
[Bug middle-end/34906] valgrind error indication from testsuite gimplify.c: gimplify_asm_expr
--- Comment #1 from ismail at pardus dot org dot tr 2008-01-21 17:13 --- Used svn revision 131650. -- ismail at pardus dot org dot tr changed: What|Removed |Added GCC target triplet||i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34906
[Bug tree-optimization/34590] GCC-4.3.0-20071221 SEGV's building Bzip2 1.0.4 decompress.c with -ftree-parallelize-loops=4
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-01-21 17:19 --- Me neither, but it now ICEs with ./cc1 -quiet -O3 -ftree-parallelize-loops=4 decompress.i decompress.c: In function 'BZ2_decompress': decompress.c:107: internal compiler error: in get_smt_for, at tree-ssa-alias.c:3267 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. (at least if hopefully that is not from my locally patched tree ;)) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34590
[Bug tree-optimization/34590] GCC-4.3.0-20071221 SEGV's building Bzip2 1.0.4 decompress.c with -ftree-parallelize-loops=4
--- Comment #7 from rakdver at gcc dot gnu dot org 2008-01-21 17:25 --- I get that ICE as well; but that is a dup of 34330 (and seems to be different from the problem described in this PR). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34590
[Bug libfortran/26253] fallback scalbn doesn't handle denormals correctly
--- Comment #10 from danglin at gcc dot gnu dot org 2008-01-21 17:25 --- Subject: Bug 26253 Author: danglin Date: Mon Jan 21 17:24:30 2008 New Revision: 131698 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131698 Log: PR libfortran/34699 Backport: 2007-09-21 Francois-Xavier Coudert [EMAIL PROTECTED] PR libfortran/26253 * intrinsics/c99_functions.c (scalbn): Use ldexp if appopriate. Modified: branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/intrinsics/c99_functions.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26253
[Bug libfortran/34699] FAIL: gfortran.fortran-torture/execute/intrinsic_set_exponent.f90 execution
--- Comment #6 from danglin at gcc dot gnu dot org 2008-01-21 17:25 --- Subject: Bug 34699 Author: danglin Date: Mon Jan 21 17:24:30 2008 New Revision: 131698 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131698 Log: PR libfortran/34699 Backport: 2007-09-21 Francois-Xavier Coudert [EMAIL PROTECTED] PR libfortran/26253 * intrinsics/c99_functions.c (scalbn): Use ldexp if appopriate. Modified: branches/gcc-4_2-branch/libgfortran/ChangeLog branches/gcc-4_2-branch/libgfortran/intrinsics/c99_functions.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34699
[Bug fortran/34901] add kind information to mismatched-types error message
--- Comment #3 from burnus at gcc dot gnu dot org 2008-01-21 17:32 --- Patch: http://gcc.gnu.org/ml/fortran/2008-01/msg00253.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-21 11:02:25 |2008-01-21 17:32:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34901
[Bug tree-optimization/34330] -ftree-parallelize-loops=4 ICE with the vectorizer also
--- Comment #5 from rakdver at gcc dot gnu dot org 2008-01-21 17:35 --- (In reply to comment #3) This is a vectorizer vs not being able to run may_alias after it can you please remind me why we can't run may_alias after the vectorizer? (and what do you think can be done about it?) As for this ICE: may_alias rebuilds the smt's, and finds that the smt for the pointers created by vectorizer should be different (based on their type, not the artificial ones created by vectorizer). If we removed the hacks to update the alias info from vectorizer and run may_alias instead, we might get type-based alias analysis related misscompilations, as we create code of form vector_type *p = object_of_arbitrary_type; *p = something; And TBA might decide that references through vector_type and arbitrary_type cannot alias. I actually tried this some time ago, and I was not able to get misscompilations this way (I am not really sure why). However, I got many fails in the testsuite (that I did not have time to investigate), so there may be some other problems with alias analysis after vectorizer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34330
[Bug target/34711] g++.dg/tree-ssa/ivopts-1.C fails for power and arm
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-01-21 17:41:07 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34711
[Bug middle-end/34621] [4.3 Regression] gcc.c-torture/execute/va-arg-25.c:32: internal compiler error: in expand_call, at calls.c:2785
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-01-21 17:46 --- (In reply to comment #6) I suspect that the patch changed bad code generation into a crash, which is not a regression... Yes it is. Anything into an ICE is a regression in my book. I thought we documented this somewhere too. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34621
