--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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:
--- 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/sh
--- 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
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.,
--- 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
--- 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
--
--- 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
-
--- 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
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 2
--- 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
--
--- 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
--- 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 (gimpl
--- 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_ca
--- 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_ca
--- 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
--- 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
--- 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
--
--- 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
sim
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 m
--- 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
--- 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
-
--- 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
-
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- 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
-
--- 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 /trun
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 __m1
--- 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
--- 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|Remo
--- 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
--- 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
--- 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
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- 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: [EMAI
--- 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-1
--- 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
--- 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 i
--- 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
--
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
--- 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
--- 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
--- 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 an
--- 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 ther
--- 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_g
--- 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
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.
--- 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
--- 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 gc
--- 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
--- 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
--- 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
--- 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
--- 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|
--- 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 d
--- 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
--- 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 yo
--- 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
--- 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
--- 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
--
--- 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.
--- 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/
--
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
[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));
--- 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
--- 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
---
--- 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):
--- 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 ba
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 returnRe
[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
--- 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 var
--- 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
--
--- 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-opti
--- 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 pr
--
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
--- 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 wit
--- 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 ta
--- 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
--
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
--
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
--
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
--
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
--
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
--
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
--
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
--
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
--
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
--
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
--
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
--
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
--- 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
---
--
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
--- 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
--- 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
Kn
--- 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
--- 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
--
1 - 100 of 103 matches
Mail list logo
