[Bug fortran/35719] pointer to zero sized array not associated
--- Comment #6 from jb at gcc dot gnu dot org 2008-05-09 06:15 --- Another solution is to have status flags for allocated and associated in the descriptor, IIRC at least Pathscale does this. Aren't there actually free bits left in the dtype flag that gfortran could use, without requiring to change the descriptor? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35719
[Bug fortran/36162] Non-ASCII character in module string gives ICE
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-09 08:03 --- Subject: Bug 36162 Author: fxcoudert Date: Fri May 9 08:02:52 2008 New Revision: 135109 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135109 Log: PR fortran/36162 * module.c (quote_string, unquote_string, mio_allocated_wide_string): New functions. (mio_expr): Call mio_allocated_wide_string where needed. * gfortran.dg/module_widestring_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/module_widestring_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36162
[Bug fortran/36162] Non-ASCII character in module string gives ICE
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-05-09 08:04 --- Fixed. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36162
[Bug c++/36185] New: wrong code with -O2 -fgcse-sm
cat -n bug.cc
1 struct Base {
2 virtual ~Base() {}
3 virtual void f() = 0;
4 };
5 struct Derived : Base {
6 Derived();
7 virtual void f() {}
8 };
9 struct Foo {
10 Foo(Base);
11 };
12
13 Derived::Derived() {
14 Foo foo(*this);
15 }
16 Foo::Foo(Base base) {
17 base.f();
18 }
19 int main() {
20 Derived d;
21 }
g++ -g -O2 -fgcse-sm bug.cc
./a.out
Segmentation fault (core dumped)
#0 0x in ?? ()
#1 0x00400775 in Derived (this=0x7fff2fc93390) at bug.cc:14
#2 0x004007ec in main () at bug.cc:20
I'm using gcc revision 135109 on linux x86_64.
--
Summary: wrong code with -O2 -fgcse-sm
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wouter dot vermaelen at scarlet dot be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36185
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Keywords||wrong-code Known to fail||4.3.1 Known to work||4.3.0 Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug middle-end/36129] [4.4 Regression] ICE with -fprofile-use
--- Comment #5 from ubizjak at gmail dot com 2008-05-09 09:12 --- Probably duplicate of or at least related to PR35215 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug rtl-optimization/36185] [4.4 Regression] wrong code with -O2 -fgcse-sm
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-09 09:21 --- Confirmed. We move parameter initialization after the call... this-D.2090._vptr.Base = _ZTV7Derived[2]; __comp_ctor (foo, this-D.2090); @@ -59,11 +59,11 @@ movq%rbx, %rsi subq$16, %rsp .LCFI1: - movq$_ZTV7Derived+16, (%rdi) leaq15(%rsp), %rdi .LEHB0: call_ZN3FooC1ER4Base .LEHE0: + movq$_ZTV7Derived+16, (%rbx) addq$16, %rsp popq%rbx ret -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |rtl-optimization Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-05-09 09:21:23 date|| Summary|wrong code with -O2 -fgcse-|[4.4 Regression] wrong code |sm |with -O2 -fgcse-sm Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36185
[Bug tree-optimization/36181] Simple for loop generates ICE with -ftree-parallelize-loops=2
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-09 09:10 ---
The integer vector operation
(gdb) call debug_generic_expr (phi)
vect_var_.32_20 = PHI vect_var_.32_21(4), { 0, 0, 0, 0 }(9)
is not considered a simple iv.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code
Known to fail||4.3.0 4.4.0
Last reconfirmed|-00-00 00:00:00 |2008-05-09 09:10:34
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36181
[Bug fortran/36186] New: Wrong handling of BOZ in CMPLX
$ cat a.f90 program test0 implicit none integer :: x = 1 write(*,*) cmplx(b'0110100101010001',1,4) write(*,*) cmplx(b'0110100101010001',x,4) end program test0 $ gfortran a.f90 $ ./a.out ( 2.6457512, 1.) ( 1.07645030E+09, 1.) This is because we don't simplify the second case, and then we convert the boz, which is represented as a maximal-size integer, into a real; as the integer is too long, that doesn't work. I believe it's the only place that can happen, as for other intrinsics, there *always* is simplification in such a case. What we should do is not too clear to me, maybe a BOZ expert could help: one thing possible is to trap that case in the simplification routine, and even if we can't simplify the whole intrinsic, we silently convert the BOZ there; or we take care of it in trans-intrinsic.c. -- Summary: Wrong handling of BOZ in CMPLX Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36186
[Bug fortran/36186] Wrong handling of BOZ in CMPLX
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2008-05-09 09:40 --- And a related issue: program test0 implicit none integer :: x = 0 write(*,*) cmplx(b'10110100101010001',x,4) end program test0 This should error with BOZ constant at (1) is too large (33 vs 32 bits), as we do for other cases, but it doesn't. This seems to imply we really should take care of all this in the simplification routine (convert the BOZ). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-09 09:40:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36186
[Bug ada/34492] corefoundation-cfbase.ads failed to compile
--- Comment #3 from sam at gcc dot gnu dot org 2008-05-09 09:46 --- This is not a GCC bug in this case, the Ptr formal parameter masks the Ptr type. -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34492
[Bug ada/34496] [4.2/4.3 Regression] prefixed notation allows changing the value of a constant
--- Comment #4 from sam at gcc dot gnu dot org 2008-05-09 09:48 --- This appears to be fixed in SVN trunk: 25.pak3.x2.p1(5); -- line 25 | actual for x1 must be a variable 27.pak3.x3.all.p1(7); -- line 27 | actual for x1 must be a variable -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|4.2.4 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34496
[Bug ada/34504] Legal program runs incorrectly, dynamic dispatching with interfaces, RM 3.9.2(5/2, 20/2), 3.9.4(1/2)
--- Comment #2 from sam at gcc dot gnu dot org 2008-05-09 09:51 --- This appears to be already fixed on SVN trunk: Do_Stuff( Thing : in D ) = 0 Finalize( Thing : in out D ) = 0 Finalize( Thing : in out D ) = -1 -- sam at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34504
[Bug other/35486] Can't build gimple-tuples-branch
--- Comment #3 from belyshev at depni dot sinp dot msu dot ru 2008-05-09 09:59 --- Fixed long ago. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added CC||belyshev at depni dot sinp ||dot msu dot ru Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35486
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #6 from riku dot voipio at iki dot fi 2008-05-09 10:05 --- The attached testcases compile now fine with gcc 4.3 branch updated to 20080501 Using built-in specs. Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.0-4' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.3.1 20080501 (prerelease) (Debian 4.3.0-4) -- riku dot voipio at iki dot fi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057
--- Comment #7 from hp at gcc dot gnu dot org 2008-05-09 10:16 --- (In reply to comment #5) I am testing this patch on x86. But hp needs to test it on the cris before i will ask for approval. The patch works with no regressions; tested against 135097 for cris-elf and crisv32-elf. Thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177
[Bug middle-end/36129] [4.4 Regression] ICE with -fprofile-use
--- Comment #6 from ubizjak at gmail dot com 2008-05-09 11:13 ---
Something interesting:
In atomic_kind_types.F.085t.copyprop3, we have:
bb 76:
D.2711_888 = *atomic_kind_38(D);
D.2731_889 = D.2711_888-element_symbol[1]{lb: 1 sz: 1};
__builtin_memcpy (element_symbol[1]{lb: 1 sz: 1}, D.2731_889, 1);
__builtin_memset (element_symbol[2]{lb: 1 sz: 1}, 32, 1);IOR value ior:0.
Average value sum:0 times:0.
goto bb 78;
and in atomic_kind_types.F.086.fab, we have:
bb 75:
D.2711_885 = *atomic_kind_38(D);
D.2731_886 = D.2711_885-element_symbol[1]{lb: 1 sz: 1};
__builtin_memmove (element_symbol[1]{lb: 1 sz: 1}, D.2731_886, 2);
goto bb 78;
As can be seen, __builtin_memset (element_symbol[2]{lb: 1 sz: 1}, 32, 1)
expression that troubles us just vanished, apparently leaving dead histogram
behind.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-05-09 11:13:09
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug middle-end/36129] [4.4 Regression] ICE with -fprofile-use
--- Comment #7 from ubizjak at gmail dot com 2008-05-09 11:18 ---
-fdump-tree-fab-details:
;; Function read_atomic_kind (__atomic_kind_types_MOD_read_atomic_kind)
Simplified
__builtin_memset (element_symbol[2]{lb: 1 sz: 1}, 32, 1);
to
(void) 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057
--- Comment #8 from zadeck at naturalbridge dot com 2008-05-09 11:20 --- Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057 hp at gcc dot gnu dot org wrote: --- Comment #7 from hp at gcc dot gnu dot org 2008-05-09 10:16 --- (In reply to comment #5) I am testing this patch on x86. But hp needs to test it on the cris before i will ask for approval. The patch works with no regressions; tested against 135097 for cris-elf and crisv32-elf. Thanks again. Bonzini, Would you review this patch? I know i am missing the bug number on the changelog. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177
[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057
--- Comment #9 from bonzini at gnu dot org 2008-05-09 11:32 --- You know I'm still not sure if I can review patches outside df* (i.e. files that do what flow.c did, but are not dataflow related), but if you think I can... then patch is ok. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177
[Bug middle-end/36129] [4.4 Regression] ICE with -fprofile-use
--- Comment #8 from ubizjak at gmail dot com 2008-05-09 11:48 ---
Patch in testing:
Index: tree-ssa-ccp.c
===
--- tree-ssa-ccp.c (revision 135108)
+++ tree-ssa-ccp.c (working copy)
@@ -2916,6 +2916,9 @@ execute_fold_all_builtins (void)
continue;
}
+ if (result)
+ gimple_remove_stmt_histograms (cfun, *stmtp);
+
if (dump_file (dump_flags TDF_DETAILS))
{
fprintf (dump_file, Simplified\n );
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug middle-end/36129] [4.4 Regression] ICE with -fprofile-use
--- Comment #9 from ubizjak at gmail dot com 2008-05-09 11:50 --- *** Bug 35215 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||astrange at ithinksw dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug middle-end/35215] ICE: verify_histograms failed with -fprofile-use
--- Comment #5 from ubizjak at gmail dot com 2008-05-09 11:50 --- The proposed patch is attached to PR36129. Should also fix this PR. *** This bug has been marked as a duplicate of 36129 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35215
[Bug tree-optimization/36129] [4.3, 4.4 Regression] ICE with -fprofile-use
--- Comment #10 from ubizjak at gmail dot com 2008-05-09 11:54 --- The same problem is on 4.3 branch, as confirmed by the dupe. -- ubizjak at gmail dot com changed: What|Removed |Added Component|middle-end |tree-optimization Known to work|4.2.3 4.3.0 | Summary|[4.4 Regression] ICE with - |[4.3, 4.4 Regression] ICE |fprofile-use|with -fprofile-use http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057
--- Comment #10 from zadeck at naturalbridge dot com 2008-05-09 11:58 --- Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057 bonzini at gnu dot org wrote: --- Comment #9 from bonzini at gnu dot org 2008-05-09 11:32 --- You know I'm still not sure if I can review patches outside df* (i.e. files that do what flow.c did, but are not dataflow related), but if you think I can... then patch is ok. :-) I had talked to david last time you raised this issue and he indicated that he thought it was fine. If someone objects, the patch can be reversed. Thanks Kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177
[Bug fortran/36117] Use MPFR for bessel function (optimization, rejects valid F2008)
--- Comment #5 from zadeck at gcc dot gnu dot org 2008-05-09 12:15 --- Subject: Bug 36117 Author: zadeck Date: Fri May 9 12:14:57 2008 New Revision: 135113 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135113 Log: 2008-05-08 Kenneth Zadeck [EMAIL PROTECTED] PR middle-end/36117 * dce.c (deletable_insn_p): Do not delete calls if df_in_progress. (delete_unmarked_insns): When deleting a call, call delete_unreachable_blocks. * rtl.texi (RTL_CONST_CALL_P, RTL_PURE_CALL_P, RTL_CONST_OR_PURE_CALL_P, RTL_LOOPING_CONST_OR_PURE_CALL_P): Fixed doc. Modified: trunk/gcc/ChangeLog trunk/gcc/dce.c trunk/gcc/doc/rtl.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36117
[Bug ada/36001] $(GNATMAKE) not defined with 'cd gcc make'
-- sam at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-09 12:24:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36001
[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057
--- Comment #11 from zadeck at naturalbridge dot com 2008-05-09 12:25
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 - 135057
zadeck at naturalbridge dot com wrote:
--- Comment #10 from zadeck at naturalbridge dot com 2008-05-09 11:58
---
Subject: Re: [4.4 Regression] g++.dg/opt/pr23714.C
ICEs with 135041 - 135057
bonzini at gnu dot org wrote:
--- Comment #9 from bonzini at gnu dot org 2008-05-09 11:32 ---
You know I'm still not sure if I can review patches outside df* (i.e. files
that do what flow.c did, but are not dataflow related), but if you think I
can... then patch is ok. :-)
I had talked to david last time you raised this issue and he indicated
that he thought it was fine.
If someone objects, the patch can be reversed.
Thanks
Kenny
commit as 135113.
2008-05-08 Kenneth Zadeck [EMAIL PROTECTED]
PR middle-end/36117
* dce.c (deletable_insn_p): Do not delete calls if
df_in_progress.
(delete_unmarked_insns): When deleting a call, call
delete_unreachable_blocks.
* rtl.texi (RTL_CONST_CALL_P, RTL_PURE_CALL_P,
RTL_CONST_OR_PURE_CALL_P, RTL_LOOPING_CONST_OR_PURE_CALL_P): Fixed
doc.
Index: doc/rtl.texi
===
--- doc/rtl.texi(revision 135089)
+++ doc/rtl.texi(working copy)
@@ -559,13 +559,36 @@ In either case GCC assumes these address
perhaps with the help of base registers.
Stored in the @code{unchanging} field and printed as @samp{/u}.
[EMAIL PROTECTED] CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] RTL_CONST_CALL_P
@cindex @code{call_insn} and @samp{/u}
@cindex @code{unchanging}, in @code{call_insn}
[EMAIL PROTECTED] CONST_OR_PURE_CALL_P (@var{x})
-In a @code{call_insn}, @code{note}, or an @code{expr_list} for notes,
-indicates that the insn represents a call to a const or pure function.
-Stored in the @code{unchanging} field and printed as @samp{/u}.
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+const function. Stored in the @code{unchanging} field and printed as
[EMAIL PROTECTED]/u}.
+
[EMAIL PROTECTED] RTL_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/i}
[EMAIL PROTECTED] @code{return_val}, in @code{call_insn}
[EMAIL PROTECTED] RTLCONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a call to a
+pure function. Stored in the @code{return_val} field and printed as
[EMAIL PROTECTED]/i}.
+
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/u} or @samp{/i}
[EMAIL PROTECTED] RTL_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn}, true if @code{RTL_CONST_CALL_P} or
[EMAIL PROTECTED] is true.
+
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P
[EMAIL PROTECTED] @code{call_insn} and @samp{/c}
[EMAIL PROTECTED] @code{call}, in @code{call_insn}
[EMAIL PROTECTED] RTL_LOOPING_CONST_OR_PURE_CALL_P (@var{x})
+In a @code{call_insn} indicates that the insn represents a possibly
+infinite looping call to a const or pure function. Stored in the
[EMAIL PROTECTED] field and printed as @samp{/c}. Only true if one of
[EMAIL PROTECTED] or @code{RTL_PURE_CALL_P} is true.
@findex INSN_ANNULLED_BRANCH_P
@cindex @code{jump_insn} and @samp{/u}
@@ -869,6 +892,9 @@ These are the fields to which the above
@item call
In a @code{mem}, 1 means that the memory reference will not trap.
+In a @code{call}, 1 means that this pure or const call may possibly
+infinite loop.
+
In an RTL dump, this flag is represented as @samp{/c}.
@findex frame_related
@@ -938,6 +964,8 @@ known not to be a member of a structure,
In @code{symbol_ref} expressions, 1 means the referenced symbol is weak.
+In @code{call} expressions, 1 means the call is pure.
+
In an RTL dump, this flag is represented as @samp{/i}.
@findex jump
@@ -967,8 +995,8 @@ instruction, 1 means an annulling branch
In a @code{symbol_ref} expression, 1 means that this symbol addresses
something in the per-function constant pool.
-In a @code{call_insn}, @code{note}, or an @code{expr_list} of notes,
-1 means that this instruction is a call to a const or pure function.
+In a @code{call_insn} 1 means that this instruction is a call to a const
+function.
In an RTL dump, this flag is represented as @samp{/u}.
Index: dce.c
===
--- dce.c (revision 135089)
+++ dce.c (working copy)
@@ -99,11 +99,16 @@ deletable_insn_p (rtx insn, bool fast)
rtx body, x;
int i;
- /* We can delete dead const or pure calls as long as they do not
- infinite loop and are not sibling calls. The problem with
- sibling calls is that it is hard to see the result. */
- if (CALL_P (insn)
+ if (CALL_P (insn)
+ /* We cannot delete calls inside of the recursive dce because
+this may cause basic blocks to be deleted and this
[Bug middle-end/36177] [4.4 Regression] g++.dg/opt/pr23714.C ICEs with 135041 - 135057
--- Comment #12 from zadeck at naturalbridge dot com 2008-05-09 12:29 --- Patch committed. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36177
[Bug c++/36185] [4.4 Regression] wrong code with -O2 -fgcse-sm
--- Comment #2 from wouter dot vermaelen at scarlet dot be 2008-05-09 13:02 --- This bug seems to be introduced in (or triggered by) revision 135053: [EMAIL PROTECTED] - still ok [EMAIL PROTECTED] - generates wrong code -- wouter dot vermaelen at scarlet dot be changed: What|Removed |Added Component|rtl-optimization|c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36185
[Bug ada/34496] [4.2/4.3 Regression] prefixed notation allows changing the value of a constant
--- Comment #5 from andreasmeier80 at gmx dot de 2008-05-09 13:18 --- Perhaps it is a good idea to add the testcase to the testsuite -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34496
[Bug tree-optimization/36187] New: [4.3 Regression] Partitioning problem with SFTs (again)
A similar problem as PR33870 is still present as seen with the attached testcase (forwarded from https://bugzilla.novell.com/show_bug.cgi?id=388664): g++-4.3 -O2 -o t testfoo.cxx ./t start test dbl2 data error 0x0 dbl2 data error 0x4002, value n was 1.00 fail e.g. interesting g++-4.3 -O2 -o t testfoo.cxx --param max-aliased-vops=600 ./t start test end test -- Summary: [4.3 Regression] Partitioning problem with SFTs (again) Product: gcc Version: 4.3.1 Status: UNCONFIRMED Keywords: wrong-code, alias Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-09 13:26 --- Created an attachment (id=15619) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15619action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-09 13:29 --- The symptom of the alias problem is that we apply store-motion to aTmp.eType = SbxDataType( p-eType | SbxBYREF ); but reads through p = aTmp; goto start; in that stmt incorrectly do not alias that store. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #5 from bonzini at gnu dot org 2008-05-09 13:36 --- Created an attachment (id=15620) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15620action=view) patch for cris problem This patch should fix the CRIS problem. However, we should also check that it does not make PR36090 resurface -- obviously. David, can you look at that? It does not attempt to fix the SPU problem, which should be fixed in the target. -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #6 from bonzini at gnu dot org 2008-05-09 13:37 --- Richard (Sandiford), could you look at the patch? You are the varasm.c expert. :-) -- bonzini at gnu dot org changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #7 from bonzini at gnu dot org 2008-05-09 13:37 --- not wrong-code, it fails to assemble. -- bonzini at gnu dot org changed: What|Removed |Added Keywords|wrong-code |rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 13:56 --- Created an attachment (id=15621) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15621action=view) more minimized testcase -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Attachment #15619|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.2.3 4.4.0 Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-09 14:09 ---
The following aborts with -O2 --param max-aliased-vops=N with N in [19, 25]
on x86_64-unknown-linux-gnu. Symptom is still lim being wrongly applied.
If you cannot reproduce it search for the correct N with
for n in `seq 0 5 100`; do g++-4.3 -O2 -S testfoo.cxx -fdump-tree-lim
-B/abuild/rguenther/gcc43-g/gcc --param max-aliased-vops=$n; grep lsm
testfoo.cxx.095t.lim /dev/null 21 echo $n; done
extern C void abort (void);
enum SbxDataType { SbxINTEGER, SbxDECIMAL, SbxBYREF = 0x4000 };
struct SbxValues {
union {
float nSingle;
float* pSingle;
};
SbxDataType eType;
};
static bool ImpPutDoubleFoo( SbxValues* p)
{
bool bRet = false;
SbxValues aTmp;
int count = 0;
start:
switch( p-eType ) {
case SbxINTEGER:
if (count++ 0)
abort ();
aTmp.pSingle = p-nSingle; goto direct;
case SbxBYREF | SbxDECIMAL:
bRet = false;
break;
direct:
aTmp.eType = SbxDataType( p-eType | SbxBYREF );
p = aTmp; goto start;
case SbxBYREF | SbxINTEGER:
break;
default:
bRet =true;
}
return bRet;
}
int main( int argc, char** argv )
{
SbxValues aTmp;
aTmp.eType = SbxINTEGER;
if ( ImpPutDoubleFoo( aTmp ) )
abort ();
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug tree-optimization/36129] [4.3, 4.4 Regression] ICE with -fprofile-use
--- Comment #11 from ubizjak at gmail dot com 2008-05-09 14:17 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00562.html. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||05/msg00562.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2008-05-09 11:13:09 |2008-05-09 14:17:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #31 from jakub at gcc dot gnu dot org 2008-05-09 14:18 ---
Alternate patch to #c12 that doesn't touch at all rs6000_legitimate_address,
just changes print_operand_address:
--- gcc/config/rs6000/rs6000.c.jj 2008-04-24 18:30:39.0 +0200
+++ gcc/config/rs6000/rs6000.c 2008-05-09 16:10:24.0 +0200
@@ -723,6 +723,7 @@ static unsigned rs6000_hash_constant (rt
static unsigned toc_hash_function (const void *);
static int toc_hash_eq (const void *, const void *);
static int constant_pool_expr_1 (rtx, int *, int *);
+static int find_constant_pool_expr (rtx *, rtx **, rtx **);
static bool constant_pool_expr_p (rtx);
static bool legitimate_small_data_p (enum machine_mode, rtx);
static bool legitimate_lo_sum_address_p (enum machine_mode, rtx, int);
@@ -3335,6 +3336,44 @@ constant_pool_expr_1 (rtx op, int *have_
}
}
+static int
+find_constant_pool_expr (rtx *op, rtx **sym, rtx **toc)
+{
+ switch (GET_CODE (*op))
+{
+case SYMBOL_REF:
+ if (RS6000_SYMBOL_REF_TLS_P (*op))
+ return 0;
+ else if (CONSTANT_POOL_ADDRESS_P (*op))
+ {
+ if (ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (get_pool_constant (*op), Pmode))
+ {
+ *sym = op;
+ return 1;
+ }
+ else
+ return 0;
+ }
+ else if (! strcmp (XSTR (*op, 0), toc_label_name))
+ {
+ *toc = op;
+ return 1;
+ }
+ else
+ return 0;
+case PLUS:
+case MINUS:
+ return (find_constant_pool_expr (XEXP (*op, 0), sym, toc)
+ find_constant_pool_expr (XEXP (*op, 1), sym, toc));
+case CONST:
+ return find_constant_pool_expr (XEXP (*op, 0), sym, toc);
+case CONST_INT:
+ return 1;
+default:
+ return 0;
+}
+}
+
static bool
constant_pool_expr_p (rtx op)
{
@@ -12268,32 +12307,36 @@ print_operand_address (FILE *file, rtx x
{
if (TARGET_AIX (!TARGET_ELF || !TARGET_MINIMAL_TOC))
{
- rtx contains_minus = XEXP (x, 1);
- rtx minus, symref;
+ rtx *symref = NULL, *tocref = NULL, toc = NULL, addr;
const char *name;
- /* Find the (minus (sym) (toc)) buried in X, and temporarily
-turn it into (sym) for output_addr_const. */
- while (GET_CODE (XEXP (contains_minus, 0)) != MINUS)
- contains_minus = XEXP (contains_minus, 0);
-
- minus = XEXP (contains_minus, 0);
- symref = XEXP (minus, 0);
- XEXP (contains_minus, 0) = symref;
+ find_constant_pool_expr (XEXP (x, 1), symref, tocref);
+ if (tocref)
+ {
+ toc = *tocref;
+ *tocref = const0_rtx;
+ }
if (TARGET_ELF)
{
char *newname;
- name = XSTR (symref, 0);
+ name = XSTR (*symref, 0);
newname = alloca (strlen (name) + sizeof (@toc));
strcpy (newname, name);
strcat (newname, @toc);
- XSTR (symref, 0) = newname;
+ XSTR (*symref, 0) = newname;
}
- output_addr_const (file, XEXP (x, 1));
+ addr = XEXP (x, 1);
+ if (GET_CODE (addr) == CONST)
+ addr = XEXP (addr, 0);
+ addr = simplify_rtx (addr);
+ if (!addr)
+ addr = XEXP (x, 1);
+ output_addr_const (file, addr);
if (TARGET_ELF)
- XSTR (symref, 0) = name;
- XEXP (contains_minus, 0) = minus;
+ XSTR (*symref, 0) = name;
+ if (tocref)
+ *tocref = toc;
}
else
output_addr_const (file, XEXP (x, 1));
The differences from #c12: 1) it doesn't reuse the same routine for finding
the addresses. The disadvantage of this is that whenever making changes to
constant_pool_expr_1 the other should be adjusted too.
2) it will silently miscompile things if more than one sym or more than one toc
is in the address (unlikely to be ever generated, true) 3) similarly, it
doesn't
check that toc is subtracted from sym, so in some pathological case we could
have
.LC1 + .LCTOC1 or -.LC1 - .LCTOC1. No testing done on the patch except for
testing that it fixes the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
-- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-09 14:21:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-05-09 14:26 --- We don't properly mark all fields of the union as base_for_components. But the real problem is probably that field-sensitive PTA doesn't consider structs with unions but we still create SFTs for them. If we didn't do that the problem with base_for_components would be avoided as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #32 from jakub at gcc dot gnu dot org 2008-05-09 14:32 ---
Actually find_constant_pool_expr can be simplified, given that
constant_pool_expr_1 had to return 1 each time.
--- gcc/config/rs6000/rs6000.c.jj 2008-04-24 18:30:39.0 +0200
+++ gcc/config/rs6000/rs6000.c 2008-05-09 16:28:39.0 +0200
@@ -723,6 +723,7 @@ static unsigned rs6000_hash_constant (rt
static unsigned toc_hash_function (const void *);
static int toc_hash_eq (const void *, const void *);
static int constant_pool_expr_1 (rtx, int *, int *);
+static void find_constant_pool_expr (rtx *, rtx **, rtx **);
static bool constant_pool_expr_p (rtx);
static bool legitimate_small_data_p (enum machine_mode, rtx);
static bool legitimate_lo_sum_address_p (enum machine_mode, rtx, int);
@@ -3335,6 +3336,32 @@ constant_pool_expr_1 (rtx op, int *have_
}
}
+static void
+find_constant_pool_expr (rtx *op, rtx **sym, rtx **toc)
+{
+ switch (GET_CODE (*op))
+{
+case SYMBOL_REF:
+ if (CONSTANT_POOL_ADDRESS_P (*op))
+ *sym = op;
+ else
+ *toc = op;
+ break;
+case PLUS:
+case MINUS:
+ find_constant_pool_expr (XEXP (*op, 0), sym, toc);
+ find_constant_pool_expr (XEXP (*op, 1), sym, toc);
+ break;
+case CONST:
+ find_constant_pool_expr (XEXP (*op, 0), sym, toc);
+ break;
+case CONST_INT:
+ break;
+default:
+ gcc_unreachable ();
+}
+}
+
static bool
constant_pool_expr_p (rtx op)
{
@@ -12268,32 +12295,36 @@ print_operand_address (FILE *file, rtx x
{
if (TARGET_AIX (!TARGET_ELF || !TARGET_MINIMAL_TOC))
{
- rtx contains_minus = XEXP (x, 1);
- rtx minus, symref;
+ rtx *symref = NULL, *tocref = NULL, toc = NULL, addr;
const char *name;
- /* Find the (minus (sym) (toc)) buried in X, and temporarily
-turn it into (sym) for output_addr_const. */
- while (GET_CODE (XEXP (contains_minus, 0)) != MINUS)
- contains_minus = XEXP (contains_minus, 0);
-
- minus = XEXP (contains_minus, 0);
- symref = XEXP (minus, 0);
- XEXP (contains_minus, 0) = symref;
+ find_constant_pool_expr (XEXP (x, 1), symref, tocref);
+ if (tocref)
+ {
+ toc = *tocref;
+ *tocref = const0_rtx;
+ }
if (TARGET_ELF)
{
char *newname;
- name = XSTR (symref, 0);
+ name = XSTR (*symref, 0);
newname = alloca (strlen (name) + sizeof (@toc));
strcpy (newname, name);
strcat (newname, @toc);
- XSTR (symref, 0) = newname;
+ XSTR (*symref, 0) = newname;
}
- output_addr_const (file, XEXP (x, 1));
+ addr = XEXP (x, 1);
+ if (GET_CODE (addr) == CONST)
+ addr = XEXP (addr, 0);
+ addr = simplify_rtx (addr);
+ if (!addr)
+ addr = XEXP (x, 1);
+ output_addr_const (file, addr);
if (TARGET_ELF)
- XSTR (symref, 0) = name;
- XEXP (contains_minus, 0) = minus;
+ XSTR (*symref, 0) = name;
+ if (tocref)
+ *tocref = toc;
}
else
output_addr_const (file, XEXP (x, 1));
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #8 from dje at gcc dot gnu dot org 2008-05-09 14:36 --- The TOC anchor SYMBOL_REF does not have an associated DECL, so the new patch crashes with a segfault. I'm not sure if there is a safe section to assume for SYMBOL_REFs without DECLs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug c++/36185] [4.4 Regression] wrong code with -O2 -fgcse-sm
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 15:04 --- Kenny, that's your PURE/CONST patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36185
[Bug tree-optimization/36188] New: missed CCP
int f(int lay)
{
static int syncsize, init;
if (init == 0)
syncsize = 1344, init = 1;
return syncsize;
}
store-ccp should handle that.
--
Summary: missed CCP
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188
[Bug tree-optimization/36188] missed CCP
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-09 15:35 --- A get_symbol_constant_value at the right place and time should do the trick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188
[Bug tree-optimization/36188] missed CCP
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-09 15:39 --- I thought I had a bug filed already ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36188
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #33 from bonzini at gnu dot org 2008-05-09 15:51 --- I now think that fixing it in the target is better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #9 from bonzini at gnu dot org 2008-05-09 16:03 --- I'll revert my patch on Monday even if no alternative solution for PR36090 is found during the weekend. It opened too big cans of worms for a release branch, even though it fixed a serious regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug target/36189] New: Invalid movabsq [EMAIL PROTECTED], %rbp for TLS
program foo implicit none common /mycom/ arr(2) !$omp threadprivate (/mycom/) integer i real*8 arr do i=1,2 write(*,*) i arr(i)=0.0d0 enddo end program compiled with -S -O2 -fopenmp with gcc 4.1/4.2 generates invalid: movabsq [EMAIL PROTECTED], %rbp @TPOFF should be used for 32-bit signed immediate though, e.g. movq [EMAIL PROTECTED], %rbp is correct. -- Summary: Invalid movabsq [EMAIL PROTECTED], %rbp for TLS Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36189
[Bug middle-end/36190] New: Investigate which tests need -fno-trapping-math
In a recent change gcc became more strict on where trapping instructions can be placed. They are no longer valid on condexprs. This introduced some regressions. The tests have been changed to use -fno-trapping-math. We should investigate if we could optimize them even with trapping math. The tests are: gcc.dg/vect/vect-111.c gcc.dg/vect/vect-ifcvt-11.c gcc.dg/vect/vect-ifcvt-12.c gcc.dg/vect/vect-ifcvt-13.c gcc.dg/vect/vect-ifcvt-14.c gcc.dg/vect/vect-ifcvt-15.c -- Summary: Investigate which tests need -fno-trapping-math Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: espindola at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36190
[Bug middle-end/36191] New: can't use complex in a eh region if non-call-exceptions is enabled
If the program
---
__complex__ double f (__complex__ double x, double y) {
try {
return x / y;
} catch (char *s) {
return x;
}
}
--
is compiled with cc1plus bug.cc -fnon-call-exceptions, it fails with the
error:
/home/espindola/bug.cc:7: error: statement marked for throw, but doesn't
D.1661 = __divdc3 (D.1667, D.1668, D.1669, D.1670);
/home/espindola/bug.cc:7: internal compiler error: verify_stmts failed
--
Summary: can't use complex in a eh region if non-call-exceptions
is enabled
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: espindola at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36191
[Bug middle-end/36191] can't use complex in a eh region if non-call-exceptions is enabled
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-09 17:08 --- Note this is most likely a regression from 3.4.0. Though -fnon-call-exceptions really is only heavily used in java and java does not use complex types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36191
[Bug target/36090] [4.3/4.4 Regression] ppc64 cacoshl miscompilation
--- Comment #34 from dje at gcc dot gnu dot org 2008-05-09 17:14 --- Subject: Bug 36090 Author: dje Date: Fri May 9 17:13:30 2008 New Revision: 135118 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135118 Log: PR target/36090 * config/rs6000/rs6000.c (print_operand_address): If the TOC address RHS contains an offset, output it as well. PR target/36182 Revert: 2008-05-08 Paolo Bonzini [EMAIL PROTECTED] PR target/36090 * simplify-rtx.c (simplify_plus_minus): Create CONST of similar RTX_CONST_OBJ before CONST_INT. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_3-branch/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36090
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #10 from dje at gcc dot gnu dot org 2008-05-09 17:14 --- Subject: Bug 36182 Author: dje Date: Fri May 9 17:13:30 2008 New Revision: 135118 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135118 Log: PR target/36090 * config/rs6000/rs6000.c (print_operand_address): If the TOC address RHS contains an offset, output it as well. PR target/36182 Revert: 2008-05-08 Paolo Bonzini [EMAIL PROTECTED] PR target/36090 * simplify-rtx.c (simplify_plus_minus): Create CONST of similar RTX_CONST_OBJ before CONST_INT. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c branches/gcc-4_3-branch/gcc/simplify-rtx.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #11 from rsandifo at nildram dot co dot uk 2008-05-09 17:17 --- Subject: Re: [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions bonzini at gnu dot org [EMAIL PROTECTED] writes: I'll revert my patch on Monday even if no alternative solution for PR36090 is found during the weekend. It opened too big cans of worms for a release branch, even though it fixed a serious regression. For the record, I think it would be easier if the rs6000 port used an unspec wrapper around the symbol, rather than a MINUS of two symbols. E.g. (const (unspec [(symbol_ref foo)] UNSPEC_TOC)) and: (const (plus (unspec [(symbol_ref foo)] UNSPEC_TOC) (const_int OFFSET))) Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug fortran/36192] New: ICE: Segmentation fault
[forwarded from http://launchpad.net/bugs/211255] The attached program causes an ICE, seen with 4.1 and 4.3 from the branches; 4.2 instead of ICEing ends with: Internal Error at (1): compare_bound(): Bad expression -- Summary: ICE: Segmentation fault Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
[Bug fortran/36192] ICE: Segmentation fault
--- Comment #1 from doko at ubuntu dot com 2008-05-09 17:47 --- Created an attachment (id=15622) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15622action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
[Bug fortran/36192] ICE: Segmentation fault
--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-09 18:04 --- While gfortran should not ICE, this program is seriously flawed with illegal Fortran. Just one example. ! Simulation parameters real, parameter :: n = 2, d = 2 ! Body masses real, dimension(n), parameter :: m = (/ 1.0, 1.0 /) ! Body parameters real, dimension(n,d) :: The arguments to dimension() should be integer type. Fix your code and the ICE may go away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
[Bug fortran/36192] ICE: Segmentation fault
--- Comment #3 from kargl at gcc dot gnu dot org 2008-05-09 18:15 --- Add -Wall to your compiler flags! any(abs(v_hq - v_n precision_goal))) then 1 Error: 'a' argument of 'abs' intrinsic at (1) must be a numeric type You have messed up parentheses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
[Bug tree-optimization/36129] [4.3, 4.4 Regression] ICE with -fprofile-use
--- Comment #12 from uros at gcc dot gnu dot org 2008-05-09 18:21 --- Subject: Bug 36129 Author: uros Date: Fri May 9 18:21:05 2008 New Revision: 135123 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135123 Log: PR tree-optimization/36129 * tree-ssa-cpp.c: Include value-prof.h. (execute_fold_all_builtins): Call gimple_remove_stmt_histograms if built-in function was folded to a constant. * Makefile.in (tree-ssa-cpp.c): Depend on value-prof.h Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug middle-end/35215] ICE: verify_histograms failed with -fprofile-use
--- Comment #6 from ubizjak at gmail dot com 2008-05-09 18:23 --- Alexander, can you apply the patch at http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00562.html to 4.3 branch and test if it fixes your ICE? I would like to backport the patch to 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35215
[Bug tree-optimization/36129] [4.3 Regression] ICE with -fprofile-use
--- Comment #13 from ubizjak at gmail dot com 2008-05-09 18:25 --- Fixed for 4.4, patch needs to be backported to 4.3 branch. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.3, 4.4 Regression] ICE |[4.3 Regression] ICE with - |with -fprofile-use |fprofile-use Target Milestone|4.4.0 |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
[Bug fortran/35719] pointer to zero sized array not associated
--- Comment #7 from tkoenig at gcc dot gnu dot org 2008-05-09 18:34 --- (In reply to comment #6) Another solution is to have status flags for allocated and associated in the descriptor, IIRC at least Pathscale does this. Aren't there actually free bits left in the dtype flag that gfortran could use, without requiring to change the descriptor? We will need to change the descriptor to fix PR 35718. Unfortunately, dtype shares space with the size, so by introducing additional bits we would be incompatible, and restrict the size of derived types further. Time for a what we want to fix with the new array descriptor meta-PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35719
[Bug rtl-optimization/33642] unrecognizable insn for -frtl-abstract-sequences
--- Comment #22 from aldot at gcc dot gnu dot org 2008-05-09 18:36 ---
$ gcc-4.4.orig-HEAD -O0 -frtl-abstract-sequences -fPIC -S foo.i -o /dev/null
foo.i: In function bazoo:
foo.i:4: error: unrecognizable insn:
(insn 23foo.i:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ cat foo.i
void bazoo (void)
{
__asm__ ();
}
works without -fPIC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33642
[Bug c++/36193] New: ICE when accessing static integer constant in template class
t.cpp
---
templatetypename T
struct B : T {
enum {N};
static const int num = N;
void f() {num;}
};
---
$ g++ -v -c t.cpp
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/cc1plus -quiet -v -D_GNU_SOURCE t.cpp
-quiet -dumpbase t.cpp -mtune=k8 -auxbase t -version -o /tmp/ccnVMPxv.s
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../x86_64-linux-gnu/include
ignoring nonexistent directory /usr/include/x86_64-linux-gnu
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/x86_64-linux-gnu
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/../../../../include/c++/4.1.2/backward
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.1.2/include
/usr/include
End of search list.
GNU C++ version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
(x86_64-linux-gnu)
compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian
4.1.1-21).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 632603bce5ef3f84603416b58939d0f7
t.cpp: In member function 'void BT::f()':
t.cpp:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.1/README.Bugs.
Preprocessed source stored into /tmp/ccci8hrp.out file, please attach this to
your bugreport.
--
Summary: ICE when accessing static integer constant in template
class
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lhyatt at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193
[Bug c++/36193] ICE when accessing static integer constant in template class
--- Comment #1 from lhyatt at gmail dot com 2008-05-09 18:46 --- Created an attachment (id=15623) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15623action=view) file producing the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193
[Bug c++/36193] ICE when accessing static integer constant in template class
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-09 18:49 --- Works at least in GCC 4.3.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193
[Bug middle-end/36194] New: [4.1/4.2/4.3/4.4 Regression] Truncation optimization in combine can remove necessary truncations
On mips64-linux-gnu the following testcase aborts:
void abort (void);
__attribute__ ((noinline)) void
f (int i)
{
if (i != 0x87654321)
abort ();
asm ();
}
__attribute__ ((noinline)) void
g (long long a)
{
f (a);
asm ();
}
main ()
{
g (0x1234567887654321ll);
return 0;
}
--
Summary: [4.1/4.2/4.3/4.4 Regression] Truncation optimization in
combine can remove necessary truncations
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: nemet at gcc dot gnu dot org
ReportedBy: nemet at gcc dot gnu dot org
GCC target triplet: mips64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36194
[Bug middle-end/36194] [4.1/4.2/4.3/4.4 Regression] Truncation optimization in combine can remove necessary truncations
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36194
[Bug c++/36193] ICE when accessing static integer constant in template class
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 19:07 --- Works with 4.1.2 and 4.0.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to fail||4.0.3 4.1.1 Known to work|4.3.0 |4.0.4 4.1.2 4.2.0 4.3.0 Resolution||FIXED Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #12 from hp at gcc dot gnu dot org 2008-05-09 19:18 --- There has been some speculation that the back-ends where the bug appear are *all* to blame by e.g. having a flawed GO_IF_LEGITIMATE_ADDRESS. A gdb session shows that the back-end validation hook that is used for the (CONST (MINUS sym2 sym1)) expression is (naturally when you think of it) LEGITIMATE_CONSTANT_P. In cases similar to the failure for CRIS, the flawed expression isn't used in an address-operand so GO_IF_LEGITIMATE_ADDRESS won't hit. But, consider the documentation, which recommends defining LEGITIMATE_CONSTANT_P to 1, which indeed most targets do; very few actually look inside a CONST, i386 being a notable exception. I think that kind of CONST should simply not be generated by gcc for now, and certainly not on the 4.3 branch. If this CONST *is* to be generated (on trunk), IMHO some new constant-expression validation needs to take place in CONSTANT_P, one where the target can refuse expressions that aren't valid assembly-code (in this case, for CRIS, sym2-sym1 where sym2 and sym1 are in different sections). Alternatively, LEGITIMATE_CONSTANT_P redefined in the documentation and most back-ends. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-05-09 19:20 --- Subject: Bug 36187 Author: rguenth Date: Fri May 9 19:19:33 2008 New Revision: 135125 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135125 Log: 2008-05-09 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36187 * tree-dfa.c (dump_variable): Correct dumping of SFT_BASE_FOR_COMPONENTS_P. * tree-ssa-structalias.c (set_uids_in_ptset): Set SFT_UNPARTITIONABLE_P correctly for the union case. * g++.dg/opt/pr36187.C: New testcase. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/opt/pr36187.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/tree-dfa.c branches/gcc-4_3-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-05-09 19:20 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.3.0 Known to work|4.2.3 4.4.0 |4.2.3 4.3.1 4.4.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug c++/36193] ICE when accessing static integer constant in template class
--- Comment #4 from lhyatt at gmail dot com 2008-05-09 19:22 --- thanks for looking into it, but I wanted to point out that it does not work on 4.1.2, at least not my build: g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) that is where I am testing it and getting the ICE. but anyway it seems like it's probably fixed in more recent versions. -- lhyatt at gmail dot com changed: What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193
[Bug middle-end/36184] gimple-tuples-branch fails bootstrap on x86 Darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-09 19:24 --- I will see what happens with this tomorrow when I get around to downloading the tuples branch on to my laptop. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|bootstrap |middle-end Summary|gimple-tuples-branch fails |gimple-tuples-branch fails |bootstrap on Darwin |bootstrap on x86 Darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36184
[Bug c++/36193] ICE when accessing static integer constant in template class
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-09 19:25 --- g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) That is a prelease and not a full release. The fix went into the 4.1 branch after that date :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193
[Bug c++/36193] ICE when accessing static integer constant in template class
--- Comment #6 from lhyatt at gmail dot com 2008-05-09 19:26 --- Subject: Re: ICE when accessing static integer constant in template class OK thanks for the quick reply; I'll see if we can get updated over here. -lewis pinskia at gcc dot gnu dot org wrote: --- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-09 19:25 --- g++ (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) That is a prelease and not a full release. The fix went into the 4.1 branch after that date :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36193
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #13 from hp at gcc dot gnu dot org 2008-05-09 19:28 --- (In reply to comment #5) Created an attachment (id=15620) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15620action=view) [edit] patch for cris problem This patch should fix the CRIS problem. Looks fine except (as the OP also mentioned), I can't see what happens when neither symbol has any information on the section. Do you need me to test it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug middle-end/35215] ICE: verify_histograms failed with -fprofile-use
--- Comment #7 from ubizjak at gmail dot com 2008-05-09 19:29 --- This is not the same failure as PR36129. It is similar, just happens in another place. It also fails on x86_64-linux-gnu. I'll look into it. -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35215
[Bug tree-optimization/35215] ICE: verify_histograms failed with -fprofile-use
--- Comment #8 from ubizjak at gmail dot com 2008-05-09 19:30 --- Taking bug. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Component|middle-end |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-05-09 19:30:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35215
[Bug tree-optimization/36187] [4.3 Regression] Partitioning problem with SFTs (again)
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-05-09 20:05 --- Subject: Bug 36187 Author: rguenth Date: Fri May 9 20:04:57 2008 New Revision: 135126 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135126 Log: 2008-05-09 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/36187 * g++.dg/opt/pr36187.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/pr36187.C - copied unchanged from r135125, branches/gcc-4_3-branch/gcc/testsuite/g++.dg/opt/pr36187.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36187
[Bug fortran/36192] ICE with wrong index types and bad parens
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-05-09 20:06 --- I can confirm that fixing the code as suggested does allow this to compile fine. Also confirming this is an ICE on invalid -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed|-00-00 00:00:00 |2008-05-09 20:06:57 date|| Summary|ICE: Segmentation fault |ICE with wrong index types ||and bad parens http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36192
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #7 from aurelien at aurel32 dot net 2008-05-09 20:19 --- This bug is actually only fixed on Debian arm EABI gcc 4.3. The problem is still present in oldABI. I guess that the problem is actually still present in upstream gcc, as Debian applies backports of libobjc and gfortran support. I am currently rebuilding gcc 4.3 on arm oldABI with the same patches to see if it fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/36194] [4.1/4.2/4.3/4.4 Regression] Truncation optimization in combine can remove necessary truncations
--- Comment #1 from nemet at gcc dot gnu dot org 2008-05-09 20:46 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00591.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36194
[Bug c/36195] New: Add warnings for useless static functions prototypes in -Wredundant-decls
Sometimes static function prototype declared with static function definition, but function is never called before definition. So prototype in such cases are definitely useless. I think will be good idea to enhance -Wredundant-decls with reporting such situation. PS May be this is already implemented in versions never then 4.1.2, but 4.3.0 manual is not mention such possibility. -- Summary: Add warnings for useless static functions prototypes in -Wredundant-decls Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eugene dot zelenko at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36195
[Bug middle-end/36075] [4.3.1 Regression] FAIL: gcc.c-torture/execute/20021119-1.c execution, -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-09 21:11 --- Ping. As the testcase in question is really simple some analysis is appreciated. On i686 the testcase is optimized to return 0 via inlining with the very first CCP pass at -O2. So I don't see how this can fail at all. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36075
[Bug middle-end/36075] [4.3.1 Regression] FAIL: gcc.c-torture/execute/20021119-1.c execution, -O2
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-05-09 21:25 --- http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg00694.html doesn't have the failure. So, fixed? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36075
[Bug rtl-optimization/36182] [4.3 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #14 from dje at gcc dot gnu dot org 2008-05-09 21:41 --- HP, If there is no CONST wrapping the difference of symbols, does the CRIS port continue to believe the address is legitimate? In other words, Paolo's patch without the CONST? I would not object to removing the CONST because that particular RTX disappears later and CONST is placed in the correct position. Separate from the specific grouping satisfying legitimate_address, the RTL does contain a difference of SYMBOL_REFs from different sections. If it is not a valid address, valid instruction, valid relocation, GCC will generate the difference as an explicit subtraction across multiple instructions because it is trying to calculate that operation. I do not understand how the operation GCC is trying to perform in the CRIS port is valid using multiple instructions. Thanks, David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36182
[Bug middle-end/36075] [4.3.1 Regression] FAIL: gcc.c-torture/execute/20021119-1.c execution, -O2
--- Comment #4 from danglin at gcc dot gnu dot org 2008-05-09 21:55 --- Appears to be fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36075
[Bug preprocessor/22231] -MG ignores missing headers even with -c
--- Comment #4 from tromey at gcc dot gnu dot org 2008-05-09 22:17 --- Subject: Bug 22231 Author: tromey Date: Fri May 9 22:17:00 2008 New Revision: 135128 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=135128 Log: gcc PR preprocessor/22231: * c-opts.c (sanitize_cpp_opts): Disallow -MG if compilation is proceeding. gcc/testsuite PR preprocessor/22231: * gcc.dg/pr22231.c: New file. Added: trunk/gcc/testsuite/gcc.dg/pr22231.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-opts.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22231
[Bug preprocessor/22231] -MG ignores missing headers even with -c
--- Comment #5 from tromey at gcc dot gnu dot org 2008-05-09 22:18 --- Fixed on trunk. It is very unlikely that this will be back-ported, so I'm closing the bug. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22231
[Bug preprocessor/28435] -MMD vs not found system header (included from a system header)
--- Comment #6 from tromey at gcc dot gnu dot org 2008-05-09 23:02 --- I think we should give an error by default, and only *not* give an error if -MG is passed. My reasoning is that -MG exists only to disable this error. I couldn't think of a reason to disable it in other cases. For instance, it seems to me that gcc -E should fail if a header is missing. I looked at open_file_failed, but I don't understand the reasoning behind a lot of the logic in there (though see PR 15220). A comment says: /* If we are outputting dependencies but not for this file then don't error because we can still produce correct output. */ ... but this seems to be based on incorrect logic to me. A include may define something which affects later inclusions. I wonder if anybody relies on the current, bogus, behavior. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28435
[Bug preprocessor/15500] gcc ignores locale when converting wide string literals to wchar_t strings
--- Comment #10 from tromey at gcc dot gnu dot org 2008-05-09 23:05 --- On further reflection I think this is very minor and I'm unlikely to back-port the fix. So, I am closing this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15500
[Bug testsuite/36196] New: gcc.dg/pr22231.c doesn't work
On Linux/ia32, I got Executing on host: /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gcc.dg/pr22231.c -MG -MD -c -fno-show-column -S -m32 -o pr22231.s(timeout = 300) cc1: error: -MG may only be used with -M or -MM^M compiler exited with status 1 output is: cc1: error: -MG may only be used with -M or -MM^M FAIL: gcc.dg/pr22231.c (test for excess errors) Excess errors: cc1: error: -MG may only be used with -M or -MM -- Summary: gcc.dg/pr22231.c doesn't work Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36196
[Bug fortran/36197] New: [4.4 Regressio]: gfortran.dg/initialization_12.f90
On Linux/ia32, gcc 4.4 revision 135109 gives Executing on host: /export/build/gnu/gcc/build-i686-linux/gcc/testsuite/gfortran/../../gfortran -B/export/build/gnu/gcc/build-i686-linux/gcc/testsuite/gfortran/../../ /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/initialization_12.f90 -O -pedantic-errors -S -o initialization_12.s(timeout = 300) *** glibc detected *** free(): invalid next size (fast): 0x09bcf970 ***^M /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/initialization_12.f90:12: internal compiler error: Aborted^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M compiler exited with status 1 output is: *** glibc detected *** free(): invalid next size (fast): 0x09bcf970 ***^M /net/gnu-13/export/gnu/src/gcc/gcc/gcc/testsuite/gfortran.dg/initialization_12.f90:12: internal compiler error: Aborted^M Please submit a full bug report,^M with preprocessed source if appropriate.^M See http://gcc.gnu.org/bugs.html for instructions.^M FAIL: gfortran.dg/initialization_12.f90 -O (internal compiler error) FAIL: gfortran.dg/initialization_12.f90 -O (test for excess errors) Revision 135106 is OK. This revision is caused by revision 135109: http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00269.html and may only happen on 32bit host. -- Summary: [4.4 Regressio]: gfortran.dg/initialization_12.f90 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36197
