[Bug target/26662] optimization on hashtable iterator produces bad code
--- Comment #2 from fang at csl dot cornell dot edu 2006-03-13 08:47 --- forgot to add: works with i686-suse-linux g++-3.3.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26662
[Bug middle-end/26643] Linux matroxfb_probe miscompiled
--- Comment #9 from matz at suse dot de 2006-03-13 08:57 --- -fno-ivopts fixes it. The problem is how bitfield refs are dealt with it seems. With -fno-ivopts the final_cleanup pass looks like so at the interesting point: D.2180 = BIT_FIELD_REF <*pdev, 32, 544> & 4294967295; ... if ((BIT_FIELD_REF <*b, 32, 0> & 4294967295) != D.2180) goto ; else goto ; ivopts lead to this code at that point: D.2180 = BIT_FIELD_REF <*pdev, 32, 544> & 4294967295; ... if ((MEM[base: (long unsigned int *) b] & 4294967295) != D.2180) goto ; else goto ; Now BIT_FIELD_REF<*b,32,0> extract exactly the 32 bit at address 'b'. But MEM[base: (long unsigned int *) b] extracts the 64 bit at that address. The masking afterwards selects the lower 32bit from that, but ppc being a big endian target this extracts the wrong half. Let's CC Zdenek for this. -- matz at suse dot de changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug middle-end/26630] [4.0 Regression] Incorrect result when subtracting, casting to short and back to int, adding and multiplying
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-13 09:02 --- Subject: Bug 26630 Author: rguenth Date: Mon Mar 13 09:02:40 2006 New Revision: 111990 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111990 Log: 2006-03-13 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/26630 * gcc.dg/torture/pr26630.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr26630.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26630
[Bug middle-end/26630] [4.0 Regression] Incorrect result when subtracting, casting to short and back to int, adding and multiplying
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-13 09:09 --- Subject: Bug 26630 Author: rguenth Date: Mon Mar 13 09:09:13 2006 New Revision: 111992 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111992 Log: 2006-03-13 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/26630 * gcc.dg/torture/pr26630.c: New testcase. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/torture/pr26630.c Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26630
[Bug middle-end/26659] [4.2 Regression] gcc.target/powerpc/ppc-vector-memset.c fails on the mainline
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-13 09:30 --- Interestingly, on i686 (which has BIGGEST_ALIGNMENT 128), I get with the testcase: Breakpoint 3, get_pointer_alignment (exp=0xb7c8b320, max_align=128) (gdb) call debug_tree(exp) unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > unsigned SI size unit size align 32 symtab 0 alias set -1> invariant arg 0 sizes-gimplified BLK size unit size align 32 symtab 0 alias set -1 domain > addressable used BLK file t.c line 5 size unit size align 32 context attributes (mem/s/c:BLK (plus:SI (reg/f:SI 54 virtual-stack-vars) (const_int -32 [0xffe0])) [0 x+0 S32 A32])>> i.e. the decl does not have alignment of 128, but 32. And we get the same alignment before and after the patch (32). Off to a ppc machine... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26659
[Bug middle-end/26659] [4.2 Regression] gcc.target/powerpc/ppc-vector-memset.c fails on the mainline
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-13 10:01 --- On powerpc64-linux I get (gdb) call debug_tree(exp) unit size align 32 symtab 0 alias set -1 precision 32 min max pointer_to_this > unsigned DI size unit size align 64 symtab 0 alias set -1> invariant arg 0 sizes-gimplified BLK size unit size align 32 symtab 0 alias set -1 domain > addressable used BLK file t.c line 5 size unit size align 128 context attributes (mem/s/c:BLK (reg/f:DI 115 virtual-stack-vars) [0 x+0 S32 A128])>> so the decl has an alignment of 128 -- I wonder why i686 is different here. So, I have a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26659
[Bug target/26662] optimization on hashtable iterator produces bad code
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-13 10:40 --- You should report this to apple, because as 4.0 and 4.1 are not affected and both the 3.3 and the 3.4 branch are now closed, this PR will be just closed as fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26662
[Bug middle-end/26659] [4.2 Regression] gcc.target/powerpc/ppc-vector-memset.c fails on the mainline
--- Comment #6 from patchapp at dberlin dot org 2006-03-13 11:20 --- Subject: Bug number PR26659 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00737.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26659
[Bug rtl-optimization/26254] [4.2 Regression] FAIL: gcc.c-torture/compile/20011109-1.c,-O1
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-03-13 12:28 --- Subject: Bug 26254 Author: rakdver Date: Mon Mar 13 12:28:09 2006 New Revision: 111998 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111998 Log: PR rtl-optimization/26254 * loop-invariant.c (seq_insns_valid_p): New function. (move_invariant_reg): Only emit new code if it is valid. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26254
[Bug rtl-optimization/26663] New: Wrong generated code with gcc-3.4.x -O2 (ok with -O1 or gcc-3.3.6)
The attached C++ code converts a floating point number from our internal representation to IEEE format. When run, the program should print a value of 144. This works with gcc-3.3.6 at any optimization level (-O1 -- -O3). With gcc-3.4.x and optimization level -O2 or -O3, it prints 42 instead. I.e., it seems the "iFloat" variable in CMdilFloat::AsFloat() is never modified. Here's the output of the code with various vanilla gcc's, along with their configuration: $ uname -a Linux xxx.xxx.com 2.6.9-22.0.2.ELsmp #1 SMP Thu Jan 5 17:13:01 EST 2006 i686 i686 i386 GNU/Linux $ gcc-3.3.6/bin/g++ -v Reading specs from /home/steffenz/gcc/install/gcc-3.3.6/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs Configured with: ../gcc-3.3.6/configure --prefix=/home/steffenz/gcc/install/gcc-3.3.6 --disable-nls --enable-languages=c,c++ Thread model: posix gcc version 3.3.6 $ gcc-3.3.6/bin/g++ -O1 -o test test.cpp && ./test 144 $ gcc-3.3.6/bin/g++ -O2 -o test test.cpp && ./test 144 $ gcc-3.3.6/bin/g++ -O3 -o test test.cpp && ./test 144 $ gcc-3.4.0/bin/g++ -v Reading specs from /home/steffenz/gcc/install/gcc-3.4.0/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Configured with: ../gcc-3.4.0/configure --prefix=/home/steffenz/gcc/install/gcc-3.4.0 --disable-nls --enable-languages=c,c++ Thread model: posix gcc version 3.4.0 $ gcc-3.4.0/bin/g++ -O1 -o test test.cpp && ./test 144 $ gcc-3.4.0/bin/g++ -O2 -o test test.cpp && ./test 42 $ gcc-3.4.0/bin/g++ -O3 -o test test.cpp && ./test 42 $ gcc-3.4.6/bin/g++ -v Reading specs from /home/steffenz/gcc/install/gcc-3.4.6/lib/gcc/i686-pc-linux-gnu/3.4.6/specs Configured with: ../gcc-3.4.6/configure --prefix=/home/steffenz/gcc/install/gcc-3.4.6 --disable-nls --enable-languages=c,c++ Thread model: posix gcc version 3.4.6 $ gcc-3.4.6/bin/g++ -O1 -o test test.cpp && ./test 144 $ gcc-3.4.6/bin/g++ -O2 -o test test.cpp && ./test 42 $ gcc-3.4.6/bin/g++ -O3 -o test test.cpp && ./test 42 -- Summary: Wrong generated code with gcc-3.4.x -O2 (ok with -O1 or gcc-3.3.6) Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: critical Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steffen dot zimmermann at philips 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=26663
[Bug rtl-optimization/26663] Wrong generated code with gcc-3.4.x -O2 (ok with -O1 or gcc-3.3.6)
--- Comment #1 from steffen dot zimmermann at philips dot com 2006-03-13 13:12 --- Created an attachment (id=11038) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11038&action=view) C++ source code to reproduce the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26663
[Bug rtl-optimization/26663] Wrong generated code with gcc-3.4.x -O2 (ok with -O1 or gcc-3.3.6)
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-13 13:37 --- This is invalid as it violates C/C++ aliasing rules. *** This bug has been marked as a duplicate of 21920 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26663
[Bug c/21920] alias violating
--- Comment #86 from rguenth at gcc dot gnu dot org 2006-03-13 13:37 --- *** Bug 26663 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||steffen dot zimmermann at ||philips dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug rtl-optimization/26254] [4.2 Regression] FAIL: gcc.c-torture/compile/20011109-1.c,-O1
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-13 13:54 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26254
[Bug target/26664] New: use of rjmp on devices with more than 2kb flash
I compile the following program with
avr-gcc -mmcu=atmega8515 -o rjmp-test rjmp-test.c
program:
const char dummy[7000] __attribute__((__progmem__));
int main() {}
-
Error:
The atmega8515 has 8Kb of flash memory. So gcc should not use
the rjmp/rcall instructions since they can only access 2Kb.
But avr-objdump shows this:
Disassembly of section .text:
<__vectors>:
0: bc cd rjmp.-1160 ; 0xfb7a
<__eeprom_e
2: d5 cd rjmp.-1110 ; 0xfbae
<__eeprom_e
4: d4 cd rjmp.-1112 ; 0xfbae
<__eeprom_e
6: d3 cd rjmp.-1114 ; 0xfbae
<__eeprom_e
8: d2 cd rjmp.-1116 ; 0xfbae
<__eeprom_e
a: d1 cd rjmp.-1118 ; 0xfbae
<__eeprom_e
c: d0 cd rjmp.-1120 ; 0xfbae
<__eeprom_e
...
Discussion:
All interrupt handlers are situated behind the 7000 byte array. Therefore
the jumps of the interrupt vectors have to span at least 7000 bytes.
That is not possible with the rjmp instruction which can span at most 2Kb.
This results in the strange negative offsets.
Solution:
Jumps which span more than 2Kb have to be encoded using "jmp" not "rjmp".
--
Summary: use of rjmp on devices with more than 2kb flash
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hochstein at algo dot informatik dot tu-darmstadt dot de
GCC build triplet: i686-pc-linux
GCC host triplet: avr
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26664
[Bug rtl-optimization/26207] [4.2 Regression] file names in rtl dumps don't match reality
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-13 14:07 --- Fixed by: 2006-03-13 Kazu Hirata <[EMAIL PROTECTED]> * doc/invoke.texi: Update dump file names. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26207
[Bug rtl-optimization/26663] Wrong generated code with gcc-3.4.x -O2 (ok with -O1 or gcc-3.3.6)
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-13 14:15 --- * (u_32 *) pFloat = 0x7FFF; // NaN That is violating C/C++ aliasing rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26663
[Bug middle-end/18859] [4.0/4.1/4.2 Regression] ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2006-03-13 14:18 --- Subject: Bug 18859 Author: ebotcazou Date: Mon Mar 13 14:18:24 2006 New Revision: 112000 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112000 Log: PR middle-end/18859 * gimplify.c (gimplify_switch_expr): Discard empty ranges. * stmt.c (expand_case): Likewise. Added: trunk/gcc/testsuite/gcc.dg/switch-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
[Bug middle-end/18859] [4.0/4.1/4.2 Regression] ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2006-03-13 14:23 --- Subject: Bug 18859 Author: ebotcazou Date: Mon Mar 13 14:23:15 2006 New Revision: 112001 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112001 Log: PR middle-end/18859 * stmt.c (expand_case): Discard empty ranges. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/switch-9.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/stmt.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
[Bug middle-end/18859] [4.0/4.1/4.2 Regression] ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-03-13 14:26 --- Subject: Bug 18859 Author: ebotcazou Date: Mon Mar 13 14:26:02 2006 New Revision: 112002 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112002 Log: PR middle-end/18859 * stmt.c (expand_case): Discard empty ranges. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/switch-9.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/stmt.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
[Bug middle-end/18859] [4.0/4.1/4.2 Regression] ACATS ICE c37305a at -O0: in tree_low_cst, at tree.c:3839
--- Comment #16 from ebotcazou at gcc dot gnu dot org 2006-03-13 14:30 --- Fixed everywhere at last. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||03/msg00572.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.1.1 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18859
[Bug target/26664] use of rjmp on devices with more than 2kb flash
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-13 14:34 --- Why do you think this is a GCC bug and not a binutils one? GCC does not produce __vectors as far as I can tell. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26664
[Bug target/26664] use of rjmp on devices with more than 2kb flash
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-13 14:37 --- On second thought this should be closed as I did a grep for __vectors and found nothing in the GCC source. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26664
[Bug rtl-optimization/26663] Wrong generated code with gcc-3.4.x -O2 (ok with -O1 or gcc-3.3.6)
--- Comment #4 from jbeitaharon at intrusic dot com 2006-03-13 14:40 --- Subject: Re: Wrong generated code with gcc-3.4.x -O2 (ok with -O1 or gcc-3.3.6) Please take me off the CC list for this distribution. I don't need the "encouragement" of knowing that many people experience similar frustrations with gcc's poor (or shall I say, uninformative) warning messages in the case of aliasing rule violations. Thanks, Jonathan pinskia at gcc dot gnu dot org wrote: >--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-13 14:15 >--- > * (u_32 *) pFloat = 0x7FFF; // NaN >That is violating C/C++ aliasing rules. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26663
[Bug c++/26665] New: Gcc segmentation fault
My code is:
//---
#include
template < int I >
struct _integer {
enum { _value = I };
typedef _integer<_value> _type;
};
#define _I(Int) \
typename _integer::_type
template< class type >
void hi(type) {
std::cout << std::endl;
}
int main() {
hi(_I(1)()); //Bug report here.
return 0;
}
//---
And my gcc command is:
g++ -O2 test.cpp -o test
//---
The bug report is:
test.cpp: In function int main():
test.cpp:72: internal compiler error: Segmentation fault
--
Summary: Gcc segmentation fault
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: babydavid at sjtu dot edu dot cn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26665
[Bug target/26664] use of rjmp on devices with more than 2kb flash
--- Comment #3 from hochstein at algo dot informatik dot tu-darmstadt dot de 2006-03-13 14:54 --- This is no gcc problem. The vectors are generated by avr-libc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26664
[Bug c++/26665] Gcc segmentation fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-13 15:02 --- This was fixed in 4.0.3 see PR 23797. *** This bug has been marked as a duplicate of 23797 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26665
[Bug c++/23797] [3.4 Regression] ICE on typename outside template
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-03-13 15:02 --- *** Bug 26665 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||babydavid at sjtu dot edu ||dot cn http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23797
[Bug middle-end/26643] [4.0/4.1/4.2 Regression] Linux matroxfb_probe miscompiled
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|Linux matroxfb_probe|[4.0/4.1/4.2 Regression] |miscompiled |Linux matroxfb_probe ||miscompiled Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug target/26655] [4.0/4.1/4.2 Regression] ICE in ix86_secondary_memory_needed, at config/i386/i386.c:16446
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-13 15:34 --- Actually this is a regression from 3.0.4. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Known to fail|3.3.3 4.1.0 4.0.0 3.4.0 |3.3.3 4.1.0 4.0.0 3.4.0 ||3.2.3 Known to work||3.0.4 2.95.3 Summary|ICE in |[4.0/4.1/4.2 Regression] ICE |ix86_secondary_memory_needed|in |, at|ix86_secondary_memory_needed |config/i386/i386.c:16446|, at ||config/i386/i386.c:16446 Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #10 from mueller at gcc dot gnu dot org 2006-03-13 16:17 --- it looks to me that this commit exposed/introduced the ICE: r111300 | dberlin | 2006-02-20 14:38:01 +0100 (Mon, 20 Feb 2006) | 22 lines Changed paths: M /trunk/gcc/ChangeLog M /trunk/gcc/passes.c M /trunk/gcc/tree-flow.h M /trunk/gcc/tree-pass.h M /trunk/gcc/tree-sra.c M /trunk/gcc/tree-ssa-alias.c M /trunk/gcc/tree-ssa-forwprop.c M /trunk/gcc/tree-ssa-operands.c M /trunk/gcc/tree.h 2006-02-20 Daniel Berlin <[EMAIL PROTECTED]> * tree.h (struct tree_memory_tag): Add is_used_alone member. (TMT_USED_ALONE): New macro. * tree-pass.h (PROP_tmt_usage): New property. (TODO_update_tmt_usage): New todo. * tree-ssa-alias.c (updating_used_alone): New variable. (recalculate_used_alone): New function. (compute_may_aliases): Set updating_used_alone, call recalculate_used_alone. * tree-sra.c (pass_sra): Note that this pass destroys PROP_tmt_usage, and add TODO_update_tmt_usage. * tree-ssa-forwprop.c (pass_forwprop): Ditto. * tree-flow.h (updating_used_alone): Prototype. (recalculate_used_alone): Ditto. * passes.c (execute_todo): Add code to set updating_used_alone, and call recalculate. * tree-ssa-operands.c (add_virtual_operand): Only append bare def for clobber if used alone, and add assert to verify used_alone status. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26667] New: Inlining always_inline functions causes further inlining that reduces function size to fail
Basically, consider the following case (shortened, full testcase will be
attached):
static __inline __m128 __attribute__((__always_inline__))
_mm_max_ps (__m128 __A, __m128 __B)
{ return (__m128) __builtin_ia32_maxps ((__v4sf)__A, (__v4sf)__B); }
static __m128 mm_max_ps(const __m128 a, const __m128 b)
{ return _mm_max_ps(a,b); }
... more wrappers ...
static bool __attribute__((always_inline)) bloatit(const __m128 a, const __m128
b)
{
const __m128
v0 = mm_max_ps(a,b),
v1 = mm_min_ps(a,b),
v2 = mm_mul_ps(a,b),
v3 = mm_div_ps(a,b),
g0 = mm_or_ps(_mm_or_ps(_mm_or_ps(v0,v1), v2), v3),
v4 = mm_min_ps(mm_or_ps(a,b),mm_div_ps(b,a)),
v5 = mm_max_ps(mm_min_ps(a,mm_div_ps(b,a)), mm_or_ps(b,
mm_div_ps(b,g0))),
g1 = mm_or_ps(g0,mm_or_ps(v4,v5));
return mm_movemask_ps(g1);
}
bool finalblow(const __m128 a, const __m128 b, const __m128 c, const __m128 d,
const __m128 e, const __m128 f)
{
return
bloatit(a,b) & bloatit(c,d) & bloatit(e,f) & bloatit(a,c) &
bloatit(b,d) & bloatit(c,e) & bloatit(d,f) &
bloatit(b,a) & bloatit(d,c) & bloatit(f,e) & bloatit(c,a) &
bloatit(d,b) & bloatit(e,c) & bloatit(f,d);
}
what happens is that as a first pass, all always_inline functions are inlined,
so bloatit will be inlined into finalblow causing the size of finalblow after
inlining to be greater than the max-function-growth limit. After that we
now decide to look at the mm_* routines used in bloatit and decide if we
can inline them into finalblow - which we do _not_ do because finalblow is
already bigger than it may get due to the function-growth limit. Even if
we correctly figure out that inlining the mm_* functions will _decrease_
the size of finalblow.
Bad.
We also incorrectly count the number of calls to mm_* in finalblow, which we
count to be zero (0).
--
Summary: Inlining always_inline functions causes further inlining
that reduces function size to fail
Product: gcc
Version: 4.1.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=26667
[Bug tree-optimization/26667] Inlining always_inline functions causes further inlining that reduces function size to fail
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-13 16:22 --- Created an attachment (id=11039) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11039&action=view) testcase Compile with -O3 -msse2, look at the optimized ipa-inline dump to see Deciding on inlining. Starting with 873 insns. Inlining always_inline functions: Considering bool bloatit(float __vector__, float __vector__) 413 insns (always inline) Inlined into bool finalblow(float __vector__, float __vector__, float __vector__, float __vector__, float __vector__, float __vector__) which now has 753 insns. ... Inlined into bool finalblow(float __vector__, float __vector__, float __vector__, float __vector__, float __vector__, float __vector__) which now has 5810 insns. Inlined for a net change of +5033 insns. Deciding on smaller functions: Considering inline candidate int mm_movemask_ps(float __vector__). Considering inline candidate float __vector__ mm_or_ps(float __vector__, float __vector__). Considering inline candidate float __vector__ mm_div_ps(float __vector__, float __vector__). Considering inline candidate float __vector__ mm_mul_ps(float __vector__, float __vector__). Considering inline candidate float __vector__ mm_min_ps(float __vector__, float __vector__). Considering inline candidate float __vector__ mm_max_ps(float __vector__, float __vector__). Considering float __vector__ mm_or_ps(float __vector__, float __vector__) with 16 insns to be inlined into bool bloatit(float __vector__, float __vector__) Estimated growth after inlined into all callees is -576 insns. Estimated badness is -147456. Not inlining into bool bloatit(float __vector__, float __vector__):--param large-function-growth limit reached. ... etc. ... doh! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26667
[Bug tree-optimization/26667] Inlining always_inline functions causes further inlining that reduces function size to fail
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-13 16:25 --- Patch for this was posted, it's not really a regression fix, though in 4.0.3 we inlined differently. Still I'd like to see the patch in 4.1.1. -- 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 URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||03/msg00739.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-13 16:25:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26667
[Bug libfortran/26661] Sequential formatted read goes too far
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-03-13 16:34 --- Created an attachment (id=11040) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11040&action=view) Example test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26661
[Bug libfortran/26661] Sequential formatted read goes too far
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-13 16:36 --- Created an attachment (id=11041) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11041&action=view) Example data file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26661
[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/
--- Comment #15 from law at redhat dot com 2006-03-13 16:37 --- Subject: Re: New: [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/ On Fri, 2006-02-17 at 18:21 +, pinskia at gcc dot gnu dot org wrote: > FAIL: gcc.dg/tree-ssa/20030730-1.c scan-tree-dump-times if 0 > FAIL: gcc.dg/tree-ssa/20030730-2.c scan-tree-dump-times if 0 > FAIL: gcc.dg/tree-ssa/20030807-2.c scan-tree-dump-times if 0 Last week's patch fixed 20030730-1.c and 2000730-2.c. This patch fixes 20030807-2.c. The existing VRP code never visits statements with virtual operands. In general, that's a good thing -- fewer statements to visit means less work and assignments with virtual operands are highly unlikely to produce useful ranges. However, there is one exception, when the RHS is a call to a built-in function. In that case we may be able to determine non-null ranges (builtin-alloca) and in some cases we can determine non-negative ranges. This patch allows VRP to visit assignments with virtual operands in this one case (RHS is a call to a built-in function). Once that's done the existing machinery will automatically discover ranges created by calls to these special built-in functions. Bootstrapped and regression tested on i686-pc-linux-gnu. --- Comment #16 from law at redhat dot com 2006-03-13 16:37 --- Created an attachment (id=11042) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11042&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
[Bug libfortran/26661] Sequential formatted read goes too far
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-13 16:37:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26661
[Bug target/26445] SSE byte-by-byte load instruction fails to compile
--- Comment #7 from gchernis11 at msn dot com 2006-03-13 16:43 --- Subject: RE: SSE byte-by-byte load instruction fails to compile Please let me know what is the status of this bug Please reply, Greg Chernis >From: "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: [EMAIL PROTECTED] >Subject: [Bug target/26445] SSE byte-by-byte load instruction fails to >compile >Date: 3 Mar 2006 20:54:42 - > >--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-03 20:54 >--- >Reducing. > > >-- > >pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > CC||pinskia at gcc dot gnu >dot >||org >Keywords||ice-on-valid-code > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26445 > >--- You are receiving this mail because: --- >You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26445
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-03-13 16:52 --- Subject: Re: [4.2 Regression] ICE in in add_virtual_operand On Mon, 2006-03-13 at 16:17 +, mueller at gcc dot gnu dot org wrote: > > --- Comment #10 from mueller at gcc dot gnu dot org 2006-03-13 16:17 > --- > it looks to me that this commit exposed/introduced the ICE: Yes, we already know that :) Thanks though. This is just another case of us catching more illegal code with this ICE (as we used to with the NMT ice). The only solution in these cases it to remove the assert and let it generate bad code, but I want to fix other issues first before removing the assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug tree-optimization/26626] [4.2 Regression] ICE in in add_virtual_operand
--- Comment #12 from mueller at gcc dot gnu dot org 2006-03-13 16:56 --- ah, I see. I'm fine with working around the ICE locally and let you guys figure out how to fix the actual cause :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26626
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-13 17:10 --- Created an attachment (id=11043) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11043&action=view) reduced test case I'm attaching a reduced test case. If you remove one of the intermediate classes, the output is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-13 17:12 ---
I added a main to the reduced test case:
public static void main(String[] args)
{
SwingFramePeer s = new SwingFramePeer();
s.setBounds();
}
With this I can almost reproduce the original bug:
opsy. gcj --main=pr26390 -o P pr26390.java
/tmp/cczetk2m.o(.text+0xd): In function `void
pr26390$SwingFramePeer::setBounds()':
pr26390.java: undefined reference to `void pr26390$WindowPeer::setBounds()'
I say "almost" since from the original report I would expect
the missing method to come from SwingWindowPeer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug middle-end/25989] gomp ICE with -O2 and schedule(guided)
-- 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|NEW |ASSIGNED Last reconfirmed|2006-01-27 12:50:51 |2006-03-13 17:15:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25989
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #20 from tkoenig at gcc dot gnu dot org 2006-03-13 17:53 --- I'll take this, implementing the simplistic approach (generating an error for >2GB record sizes). This should keep the complexity down. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-05 20:01:55 |2006-03-13 17:53:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug target/26508] 4.1.0 doesn't build in 64bit on PA-RISC
--- Comment #19 from h dot m dot brand at xs4all dot nl 2006-03-13 18:03 --- As development perl was unable to complete it's testsuite with the installed 4.1.0/64, I went back to 4.0.3, where all works well. FYI pack and udp failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26508
[Bug target/26508] 4.1.0 doesn't build in 64bit on PA-RISC
--- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-13 18:10 --- Subject: Re: 4.1.0 doesn't build in 64bit on PA-RISC > As development perl was unable to complete it's testsuite with the installed > 4.1.0/64, I went back to 4.0.3, where all works well. > > FYI pack and udp failures. There may not be another 4.0 release, so it would be useful if you could determine why these tests fail and submit PRs. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26508
[Bug java/26390] Problem dispatching method call when method does not exist in superclass
--- Comment #7 from tromey at gcc dot gnu dot org 2006-03-13 19:07 --- The bug here is that gcj implements method inheritance incorrectly. In particular it does not consider SwingWindowPeer.setBounds as a candidate method for the super.setBounds() call, because it has no notion that there is a method named "SwingWindowPeer.setBounds". Instead it only considers SwingComponentPeer.setBounds -- which is not maximal and thus not selected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26390
[Bug middle-end/25989] gomp ICE with -O2 and schedule(guided)
--- Comment #3 from jakub at gcc dot gnu dot org 2006-03-13 19:36 --- Subject: Bug 25989 Author: jakub Date: Mon Mar 13 19:36:19 2006 New Revision: 112023 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112023 Log: PR middle-end/25989 * omp-low.c (expand_omp_for_generic): Mark istart0 and iend0 as addressable. * gcc.dg/gomp/pr25989.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr25989.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25989
[Bug c++/26669] lost temporary
--- Comment #1 from igodard at pacbell dot net 2006-03-13 20:19 --- Created an attachment (id=11045) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11045&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26669
[Bug c++/26669] New: lost temporary
Compiling and running the attached code produces: ~/ootbc/common/test$ build/wideIntTest 0x12345678:0x8000:0x01234567:0x81234567:0x8000bc50 The first four hex outputs shows the expression done one subexpression at a time, and produces the correct result. The last hex shows the expression result as a single expression, and the result is wrong and the values contains what looks like an address. I guess that a temporary in the expression evaluation got overwritten. Ivan -- Summary: lost temporary Product: gcc Version: 4.0.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26669
[Bug target/26662] optimization on hashtable iterator produces bad code
--- Comment #5 from fang at csl dot cornell dot edu 2006-03-13 20:51 --- Filed to Apple. For the record, this is Bug #4476031 on the Radar, for those who might have access. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26662
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #7 from law at redhat dot com 2006-03-13 21:17 --- Subject: Re: [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops On Wed, 2006-03-08 at 00:07 +, janis at gcc dot gnu dot org wrote: > > --- Comment #5 from janis at gcc dot gnu dot org 2006-03-08 00:07 --- > A regression hunt on powerpc64-linux using the C test case from comment #4 > identified this patch: > > http://gcc.gnu.org/viewcvs?view=rev&rev=110705 > > r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006) > > > That date doesn't match up with when the Fortran test started failing so I ran > another regression hunt using it, which identified this patch: > > http://gcc.gnu.org/viewcvs?view=rev&rev=108425 > > r108425 | law | 2005-12-12 19:59:16 + (Mon, 12 Dec 2005) What I suspect is going on here is that we've got a latent bug in the RTL IV code. The patches referenced above merely expose instances of that underlying latent bug. I'm still trying to learn my way around the RTL IV code, if I can't figure it out pretty quickly I'll have to hand this off to Zdenek. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #90 from pluto at agmk dot net 2006-03-13 20:17 --- with 4.1.1 snapshot + patches I get an arts crash today on my x86_64 box. Starting program: /usr/bin/artsd Program received signal SIGSEGV, Segmentation fault. 0x2af641d8 in __gnu_cxx::__mt_alloc >::allocate () from /usr/lib64/libartsflow.so.1 (gdb) bt #0 0x2af641d8 in __gnu_cxx::__mt_alloc >::allocate () from /usr/lib64/libartsflow.so.1 #1 0x2ba4a908 in std::_Deque_base >::_M_initialize_map () from /usr/lib64/libmcop.so.1 #2 0x2ba49145 in Arts::NotificationManager::NotificationManager () from /usr/lib64/libmcop.so.1 #3 0x2ba2660a in Arts::Dispatcher::Dispatcher () from /usr/lib64/libmcop.so.1 #4 0x0041c227 in main (argc=1, argv=0x7fe818f8) at artsd.cc:275 arts works fine with visibiliy feature disabled. $ gcc -v Reading specs from /usr/lib64/gcc/x86_64-pld-linux/4.1.1/specs Target: x86_64-pld-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-shared --enable-threads=posix --enable-languages=c,c++,fortran,objc,obj-c++,ada,java --enable-c99 --enable-long-long --enable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib64 --without-system-libunwind --enable-cmath --with-long-double-128 --with-gxx-include-dir=/usr/include/c++/4.1.1 --disable-libstdcxx-pch --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --with-qt4dir=/usr/lib64/qt4 --disable-libjava-multilib --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo --enable-java-awt=qt,gtk,xlib --enable-jni --enable-xmlj --enable-alsa --enable-dssi x86_64-pld-linux Thread model: posix gcc version 4.1.1 20060308 (prerelease) (PLD-Linux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug c++/26669] lost temporary
--- Comment #2 from igodard at pacbell dot net 2006-03-13 20:20 --- Created an attachment (id=11046) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11046&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26669
[Bug target/26662] optimization on hashtable iterator produces bad code
--- Comment #4 from fang at csl dot cornell dot edu 2006-03-13 20:21 --- (In reply to comment #3) > You should report this to apple, because as 4.0 and 4.1 are not affected and > both the 3.3 and the 3.4 branch are now closed, this PR will be just closed as > fixed. > Ok, I accept, as expected. But can I get an opinion on the validity of my code before I report this to them, especially regarding my use of hash_map::iterator? (perhaps a confirmation of reproducibility too, at least on powerpc-apple-darwin7-g++-3.3, from someone who has it?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26662
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-13 21:30 --- Subject: Re: [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops > > r108425 | law | 2005-12-12 19:59:16 + (Mon, 12 Dec 2005) > What I suspect is going on here is that we've got a latent > bug in the RTL IV code. The patches referenced above merely > expose instances of that underlying latent bug. We have the following IV bug still open on the PA: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244 Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug middle-end/25989] gomp ICE with -O2 and schedule(guided)
--- Comment #4 from jakub at gcc dot gnu dot org 2006-03-13 21:44 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25989
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #9 from law at redhat dot com 2006-03-13 21:45 --- Subject: Re: [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops On Mon, 2006-03-13 at 21:31 +, dave at hiauly1 dot hia dot nrc dot ca wrote: > > --- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-13 > 21:30 --- > Subject: Re: [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 > -fomit-frame-pointer -funroll-loops > > > > r108425 | law | 2005-12-12 19:59:16 + (Mon, 12 Dec 2005) > > What I suspect is going on here is that we've got a latent > > bug in the RTL IV code. The patches referenced above merely > > expose instances of that underlying latent bug. > > We have the following IV bug still open on the PA: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26244 Thanks. I doubt the problems in 26244 and 25569 are related. 26244 is a code generation error apparently related to loop invariant code motion, 25569 is an ICE due to unrolling. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug c/24542] potential integer overflow should be warned on assignment to wider variable
--- Comment #7 from alexey at hyperroll dot com 2006-03-13 21:49 --- (In reply to comment #6) So, who is actually going to fix the issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
[Bug c++/26669] lost temporary
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-13 21:50 ---
Not a bug, you are returning a reference to a local variables in:
friend
const
T& operator << (T t, const Arg& s) { return t <<= s; }
friend
const
T& operator >> (T t, const Arg& s) { return t >>= s; }
If you change the return type to T instead of T&, this works correctly, this is
hard to warn about since >>= returns a reference to t.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26669
[Bug c/24542] potential integer overflow should be warned on assignment to wider variable
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-13 21:52 --- (In reply to comment #7) > So, who is actually going to fix the issue? If you want it fixed, you should update it to the mainline and then post the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24542
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #10 from law at redhat dot com 2006-03-13 22:14 ---
Subject: Re: [4.2 Regression] FAIL:
gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
On Wed, 2006-03-08 at 00:07 +, janis at gcc dot gnu dot org wrote:
>
> --- Comment #5 from janis at gcc dot gnu dot org 2006-03-08 00:07 ---
> A regression hunt on powerpc64-linux using the C test case from comment #4
> identified this patch:
>
> http://gcc.gnu.org/viewcvs?view=rev&rev=110705
>
> r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006)
>
>
> That date doesn't match up with when the Fortran test started failing so I ran
> another regression hunt using it, which identified this patch:
>
> http://gcc.gnu.org/viewcvs?view=rev&rev=108425
>
> r108425 | law | 2005-12-12 19:59:16 + (Mon, 12 Dec 2005)
>
Zdenek -- can you take a closer look at this -- you're a lot more
familiar with the loop unroller than I am.
This bugzilla entry has two testcases which ICE in the "new"
unrolling code at least two platforms (PA64, PPC64).
In analyze_iv_to_split_insn we have:
ok = iv_analyze_result (insn, dest, &iv);
gcc_assert (ok);
>From reading loop-unroll.c, I believe that we could safely have
analyze_iv_to_split_insn return NULL instead of aborting when
iv_analyze_result returns false.
However, I wouldn't want to make such a change without first
giving you the opportunity to look at the code and indicate
if such a change is just papering over a problem elsewhere in
the IV code.
For the fortran testcase using a i686-pc-linux-gnu-x-powerpc64-linux
cross compiler we have the following code in a loop:
(insn 35 34 36 5 (set (reg:SI 126)
(plus:SI (subreg/s:SI (reg:DI 123 [ D.885 ]) 4)
(const_int 1 [0x1]))) 78 {*addsi3_internal1} (nil)
(nil))
(insn 36 35 38 5 (set (reg/v:DI 122 [ i ])
(sign_extend:DI (reg:SI 126))) 27 {*rs6000.md:367} (nil)
(nil))
(insn 38 36 39 5 (set (reg:DI 123 [ D.885 ])
(zero_extend:DI (subreg:QI (reg/v:DI 122 [ i ]) 7))) 12
{*zero_extendqidi2_internal1} (nil)
(nil))
(insn 39 38 40 5 (set (reg:CC 127)
(compare:CC (subreg/s:SI (reg:DI 123 [ D.885 ]) 4)
(subreg/s:SI (reg/v:DI 122 [ i ]) 4))) 414
{*cmpsi_internal1} (nil)
(nil))
We blow up trying to analyze insn 38 -- which of course requires
us to look at insns 36 & 35.
iv_analyze_result ultimately returns false because iv_subreg
returned false for the following case:
iv->base(reg:DI 123 [ D.885 ])
iv->step(const_int 1)
iv->extend ZERO_EXTEND
iv->extend_mode DImode
iv->modeQImode
iv->first_special 1
The mode parameter is SImode.
We trigger this code:
401 if (GET_MODE_BITSIZE (mode) > GET_MODE_BITSIZE (iv->mode))
402 return false;
ie, if we're asking iv_subreg to extend from a narrow mode to
a wider mode via a subreg-like operation, then iv_subreg returns
false. That eventually bubbles up to analyze_iv_to_split_insn
and triggers the ICE.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug c++/26660] [4.2 Regression] PCH vs -save-temps, ICE while GCing
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-13 22:32 --- This worked with "4.2.0 20060306" so it has to be a recent change. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|x86-64-linux-gnu| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26660
[Bug c++/26660] [4.2 Regression] PCH vs -save-temps, ICE while GCing
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-13 22:34 --- This is a blocker as I reduced it from a failing libstdc++ testcase. CCing the developers of the openmp patch since that is the only patch to the C++ front-end which could have caused this within the dates I gave. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||dnovillo at redhat dot com, ||jakub at redhat dot com Severity|normal |blocker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26660
[Bug libfortran/25378] [Fortran 2003] maxloc for all-false mask
--- Comment #4 from pault at gcc dot gnu dot org 2006-03-13 22:50 --- Subject: Bug 25378 Author: pault Date: Mon Mar 13 22:49:56 2006 New Revision: 112028 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112028 Log: 2006-03-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25378 * trans-intrinsic.c (gfc_conv_intrinsic_minmaxloc): Set the initial position to zero and modify the condition for updating it, to implement the F2003 requirement for all(mask) is false. 2006-03-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25378 * libgfortran/m4/minloc1.m4: Set the initial position to zero and modify the condition for updating it, to implement the F2003 requirement for all(mask).eq.false. * libgfortran/m4/maxloc1.m4: The same. * libgfortran/m4/iforeach.m4: The same. * libgfortran/m4/minloc0.m4: The same. * libgfortran/m4/maxloc0.m4: The same. * libgfortran/generated/maxloc0_16_i16.c: Regenerated, together with 41 others. * libgfortran/generated/minloc0_16_i16.c: Regenerated, together with 41 others. 2006-03-13 Paul Thomas <[EMAIL PROTECTED]> PR fortran/25378 * gfortran.fortran-torture/execute/intrinsic_mmloc_3.f90: Expand test to include more permuatations of mask and index. * testsuite/gfortran.dg/scalar_mask_1.f90: Modify last test to respond to F2003 spec. that the position returned for an all false mask && condition is zero. Modified: trunk/configure trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/scalar_mask_1.f90 trunk/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_mmloc_3.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/generated/maxloc0_16_i16.c trunk/libgfortran/generated/maxloc0_16_i4.c trunk/libgfortran/generated/maxloc0_16_i8.c trunk/libgfortran/generated/maxloc0_16_r10.c trunk/libgfortran/generated/maxloc0_16_r16.c trunk/libgfortran/generated/maxloc0_16_r4.c trunk/libgfortran/generated/maxloc0_16_r8.c trunk/libgfortran/generated/maxloc0_4_i16.c trunk/libgfortran/generated/maxloc0_4_i4.c trunk/libgfortran/generated/maxloc0_4_i8.c trunk/libgfortran/generated/maxloc0_4_r10.c trunk/libgfortran/generated/maxloc0_4_r16.c trunk/libgfortran/generated/maxloc0_4_r4.c trunk/libgfortran/generated/maxloc0_4_r8.c trunk/libgfortran/generated/maxloc0_8_i16.c trunk/libgfortran/generated/maxloc0_8_i4.c trunk/libgfortran/generated/maxloc0_8_i8.c trunk/libgfortran/generated/maxloc0_8_r10.c trunk/libgfortran/generated/maxloc0_8_r16.c trunk/libgfortran/generated/maxloc0_8_r4.c trunk/libgfortran/generated/maxloc0_8_r8.c trunk/libgfortran/generated/maxloc1_16_i16.c trunk/libgfortran/generated/maxloc1_16_i4.c trunk/libgfortran/generated/maxloc1_16_i8.c trunk/libgfortran/generated/maxloc1_16_r10.c trunk/libgfortran/generated/maxloc1_16_r16.c trunk/libgfortran/generated/maxloc1_16_r4.c trunk/libgfortran/generated/maxloc1_16_r8.c trunk/libgfortran/generated/maxloc1_4_i16.c trunk/libgfortran/generated/maxloc1_4_i4.c trunk/libgfortran/generated/maxloc1_4_i8.c trunk/libgfortran/generated/maxloc1_4_r10.c trunk/libgfortran/generated/maxloc1_4_r16.c trunk/libgfortran/generated/maxloc1_4_r4.c trunk/libgfortran/generated/maxloc1_4_r8.c trunk/libgfortran/generated/maxloc1_8_i16.c trunk/libgfortran/generated/maxloc1_8_i4.c trunk/libgfortran/generated/maxloc1_8_i8.c trunk/libgfortran/generated/maxloc1_8_r10.c trunk/libgfortran/generated/maxloc1_8_r16.c trunk/libgfortran/generated/maxloc1_8_r4.c trunk/libgfortran/generated/maxloc1_8_r8.c trunk/libgfortran/generated/minloc0_16_i16.c trunk/libgfortran/generated/minloc0_16_i4.c trunk/libgfortran/generated/minloc0_16_i8.c trunk/libgfortran/generated/minloc0_16_r10.c trunk/libgfortran/generated/minloc0_16_r16.c trunk/libgfortran/generated/minloc0_16_r4.c trunk/libgfortran/generated/minloc0_16_r8.c trunk/libgfortran/generated/minloc0_4_i16.c trunk/libgfortran/generated/minloc0_4_i4.c trunk/libgfortran/generated/minloc0_4_i8.c trunk/libgfortran/generated/minloc0_4_r10.c trunk/libgfortran/generated/minloc0_4_r16.c trunk/libgfortran/generated/minloc0_4_r4.c trunk/libgfortran/generated/minloc0_4_r8.c trunk/libgfortran/generated/minloc0_8_i16.c trunk/libgfortran/generated/minloc0_8_i4.c trunk/libgfortran/generated/minloc0_8_i8.c trunk/libgfortran/generated/minloc0_8_r10.c trunk/libgfortran/generated/minloc0_8_r16.c trunk/libgfortran/generated/minloc0_8_r4.c trunk/libgfortran/generated/minloc0_8_r8.c trunk/libgfortran/generated/minloc1_16_i16.c trunk/libgfortran/generated/minloc1_16_i4.c trunk/libgfortran/generated/minloc1_16_i8.c trunk/libgfortran/generated/
[Bug middle-end/26643] [4.0/4.1/4.2 Regression] Linux matroxfb_probe miscompiled
-- 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 |2006-03-13 23:04:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug c++/26670] New: attribute((packed)) sometimes not ignored for non-PODs
[forwarded from http://bugs.debian.org/356548]
Under some circumstances, non-PODs are not properly stripped of their
packedness:
struct nonpod {
nonpod();
};
struct nonpod_pack {
nonpod n;
} __attribute__ ((packed));
struct nonpod_pack2 {
nonpod_pack p;
} __attribute__ ((packed));
gives
foo.cc:6: warning: ignoring packed attribute on unpacked non-POD field 'nonpod
nonpod_pack::n'
nonpod_pack2::p should also have the packedness ignored, since it is a non-POD.
--
Summary: attribute((packed)) sometimes not ignored for non-PODs
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26670
[Bug c++/26670] attribute((packed)) sometimes not ignored for non-PODs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-13 23:15 --- Hmm, it does not warn about non-PODs which contain non-PODS which had been warned about already. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nathan at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26670
[Bug target/25642] optimizer bug: registers are clobbered but not restored
--- Comment #3 from schwab at suse dot de 2006-03-13 23:19 --- The ABI guarantees that register a5 is preserved across calls. I can't see anything violating this assumption. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25642
[Bug middle-end/26557] [4.0/4.1/4.2 Regression] ICE in simplify_subreg
--- Comment #3 from sayle at gcc dot gnu dot org 2006-03-13 23:47 --- Subject: Bug 26557 Author: sayle Date: Mon Mar 13 23:47:47 2006 New Revision: 112032 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112032 Log: PR middle-end/26557 * stmt.c (emit_case_nodes): Handle the case where the index is a CONST_INT, where the comparison mode is specified by the index type. * gcc.c-torture/compile/switch-1.c: New test case. Added: trunk/gcc/testsuite/gcc.c-torture/compile/switch-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/stmt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26557
[Bug c++/26670] attribute((packed)) sometimes not ignored for non-PODs
--- Comment #2 from debian-gcc at lists dot debian dot org 2006-03-13
23:53 ---
It's not just a missing warning, it also changes behavior:
int& foo(nonpod_pack& n) {
return n.n.i; // this passes
}
int& foo(nonpod_pack2& p) {
return p.p.n.i; // this barfs
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26670
[Bug c++/26671] New: Missing "warning: reference to local variable returned"
class test
{
public:
int secondMember;
};
class test2
{
public:
int requiredForTest;
int secondMember;
};
int &
returnRefToLocalOK()
{
test local;
return local.secondMember;
}
int &
returnRefToLocalMissing()
{
test2 local;
return local.secondMember;
}
int
main()
{
return returnRefToLocalOK();
return returnRefToLocalMissing();
}
===
gcc fails to generate the warning "reference to local variable returned" for
function returnRefToLocalMissing().
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs
Configured with: ../configure
Thread model: posix
gcc version 3.3.6
the command line and resulting output:
gcc test.cc
test.cc: In function `int& returnRefToLocalOK()':
test.cc:16: warning: reference to local variable `local' returned
the preprocessed file:
# 1 "test.cc"
# 1 ""
# 1 ""
# 1 "test.cc"
class test
{
public:
int secondMember;
};
class test2
{
public:
int requiredForTest;
int secondMember;
};
int &
returnRefToLocalOK()
{
test local;
return local.secondMember;
}
int &
returnRefToLocalMissing()
{
test2 local;
return local.secondMember;
}
int
main()
{
return returnRefToLocalOK();
return returnRefToLocalMissing();
}
Also occurs in gcc versions 3.3.3 through 3.3.5.
--
Summary: Missing "warning: reference to local variable returned"
Product: gcc
Version: 3.3.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carolh at sinavigator dot com
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26671
[Bug middle-end/26672] New: ICE in op_iter_init, triggered by printf->puts optimization
[forwarded from http://bugs.debian.org/356231]
found in 4.1 and in 4.2.0 20060304
not found in 3.4, 4.0
[EMAIL PROTECTED]:/src/delta/bin% cat mini.c
int printf(const char *format, ...);
extern const char help_string[];
void app_opts(void) {
printf("%s", help_string);
}
const char help_string[] = "foo\n";
[EMAIL PROTECTED]:/src/delta/bin% gcc -c mini.c
[EMAIL PROTECTED]:/src/delta/bin% gcc -c mini.c -O
mini.c: In function 'app_opts':
mini.c:6: internal compiler error: in op_iter_init, at tree-flow-inline.h:1036
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE in op_iter_init, triggered by printf->puts
optimization
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26672
[Bug c++/26671] [4.0/4.1/4.2 Regression] Missing "warning: reference to local variable returned"
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-14 00:10 --- It is even worse in 4.0.0 and above where we don't warn at all, I will look into this later this week. I am going to mark this as a regression for 4.0 because I think my fix will also fix both reference to local variable problem. Oh and the C front-end is not affected. Related to the old PR 14156. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Known to fail||4.0.0 4.1.0 4.2.0 Last reconfirmed|-00-00 00:00:00 |2006-03-14 00:10:44 date|| Summary|Missing "warning: reference |[4.0/4.1/4.2 Regression] |to local variable returned" |Missing "warning: reference ||to local variable returned" Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26671
[Bug tree-optimization/26672] [4.1/4.2 Regression] ICE in op_iter_init, triggered by printf->puts optimization
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-14 00:15 --- Hmm, The problem is really we are looking at the VOPS pre going into SSA in set_rhs. That seems wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2006-03-14 00:15:48 date|| Summary|ICE in op_iter_init,|[4.1/4.2 Regression] ICE in |triggered by printf->puts |op_iter_init, triggered by |optimization|printf->puts optimization Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26672
[Bug rtl-optimization/25739] Memory leak in bt_load.c(augment_live_range)
--- Comment #4 from sayle at gcc dot gnu dot org 2006-03-14 00:24 --- Subject: Bug 25739 Author: sayle Date: Tue Mar 14 00:24:54 2006 New Revision: 112039 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112039 Log: 2006-03-13 Uttam Pawar <[EMAIL PROTECTED]> PR rtl-optimization/25739 * bt-load.c (augment_live_range): Free tos pointer. * gensupport.c (identify_predicable_attribute): Free p_false pointer. * gcov.c (create_file_names): Free name pointer. Modified: trunk/gcc/ChangeLog trunk/gcc/bt-load.c trunk/gcc/gcov.c trunk/gcc/gensupport.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25739
[Bug middle-end/26643] [4.0/4.1/4.2 Regression] Linux matroxfb_probe miscompiled
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-03-14 01:01 --- The following patch should fix the problem. I am fairly sure a similar check used to be somewhere in ivopts, but it probably got lost when MEM_REFs were introduced (I am somewhat surprised ivopts do not ICE and produce something that actually resembles a correct code in this case...) Index: tree-ssa-loop-ivopts.c === *** tree-ssa-loop-ivopts.c (revision 111993) --- tree-ssa-loop-ivopts.c (working copy) *** find_interesting_uses_address (struct iv *** 1482,1489 /* Ignore bitfields for now. Not really something terribly complicated to handle. TODO. */ ! if (TREE_CODE (base) == COMPONENT_REF ! && DECL_NONADDRESSABLE_P (TREE_OPERAND (base, 1))) goto fail; if (STRICT_ALIGNMENT --- 1482,1490 /* Ignore bitfields for now. Not really something terribly complicated to handle. TODO. */ ! if (TREE_CODE (base) == BIT_FIELD_REF ! || (TREE_CODE (base) == COMPONENT_REF ! && DECL_NONADDRESSABLE_P (TREE_OPERAND (base, 1 goto fail; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26643
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
-- 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|2006-03-06 14:53:26 |2006-03-14 01:03:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-03-14 01:10 --- >From reading loop-unroll.c, I believe that we could safely have >analyze_iv_to_split_insn return NULL instead of aborting when >iv_analyze_result returns false. >However, I wouldn't want to make such a change without first >giving you the opportunity to look at the code and indicate >if such a change is just papering over a problem elsewhere in >the IV code. This is definitely a bug in loop-iv.c -- once biv_p (SET_DEST (single_set (insn))) returns true, iv_analyze_result must succeed as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug target/26657] With -fopenmp, gcc does not link with -lgomp
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-14 01:19 --- Subject: Bug 26657 Author: pinskia Date: Tue Mar 14 01:19:16 2006 New Revision: 112041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112041 Log: 2006-03-14 Andrew Pinski <[EMAIL PROTECTED]> PR target/26657 * config/darwin.h (LINK_COMMAND_SPEC): Handle -fopenmp. Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26657
[Bug target/26657] With -fopenmp, gcc does not link with -lgomp
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-14 01:19 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26657
[Bug fortran/22519] Memory and binary disk layout disagree for real*10
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22519
[Bug ada/19323] ACATS cdd2a03 fails at compile time
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19323
[Bug libfortran/24224] Generalized internal array IO not implemented.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24224
[Bug ada/24354] ACATS FAIL cxg1003 on x86-linux at -O1 -finline-functions -funroll-loops
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24354
[Bug fortran/25045] [4.1 only] DIM argument of PRODUCT is not optional
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25045
[Bug fortran/25075] [4.1 only] array size mismatch in DOT_PRODUCT
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25075
[Bug fortran/23092] [4.1 only] scalar mask for minval/maxval/sum/product
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23092
[Bug fortran/16136] Conflicting attributes ALLOCATABLE, DUMMY (F2003)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16136
[Bug fortran/25786] [meta-bug] assumed length/sized problems
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25786
[Bug target/26588] gfortran -fopenmp passes unrecognised -pthread
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26588
[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26554
[Bug c++/25952] -fopenmp causes ICE on valid code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25952
[Bug tree-optimization/20168] const function causes the creation of GLOBAL_VAR
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-14 01:28 --- Huh, I still get a .global_var as of yesterday: # .GLOBAL_VAR_6 = V_MAY_DEF <.GLOBAL_VAR_5>; bambam (); -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20168
[Bug middle-end/25989] gomp ICE with -O2 and schedule(guided)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25989
[Bug rtl-optimization/25739] Memory leak in bt_load.c(augment_live_range)
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-14 01:30 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25739
[Bug middle-end/26557] [4.0/4.1 Regression] ICE in simplify_subreg
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-14 01:31 --- Fix is now on the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.3 4.0.2 4.1.0 4.2.0 |4.0.3 4.0.2 4.1.0 Known to work|3.4.0 |3.4.0 4.2.0 Summary|[4.0/4.1/4.2 Regression] ICE|[4.0/4.1 Regression] ICE in |in simplify_subreg |simplify_subreg http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26557
[Bug java/26437] java build fails with relocation R_X86_64_32 error
--- Comment #7 from quanah at stanford dot edu 2006-03-14 03:28 --- gcc 4.0.3 builds for me without issue on the AMD 64, so the issue I hit must have been something fixed between 4.0.2 and 4.0.3. This can be closed. --Quanah -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26437
[Bug java/26437] java build fails with relocation R_X86_64_32 error
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-14 03:30 --- Reporter reports this is fixed so closing as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26437
