--- Comment #6 from veksler at il dot ibm dot com 2007-01-17 08:49 ---
(In reply to comment #0)
The program below shows (at all the optimization levels) a miscompilation of
the remainder expression that causes INT_MIN % -1 to cause a SIGFPE on CPUs of
the i386 family.
For the record
--- Comment #10 from bugzilla at bennee dot com 2007-01-17 10:35 ---
(In reply to comment #9)
(In reply to comment #4)
Testcase compiles OK with gcc version 4.3.0 20070115 (experimental).
Uh, I was compiling in 32bit mode. For x86_64 compilation fails as documented
in comment #3.
--- Comment #2 from pault at gcc dot gnu dot org 2007-01-17 10:44 ---
Confirmed.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #42 from mueller at gcc dot gnu dot org 2007-01-17 10:51
---
no, its going in real soon now (finally) :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
--- Comment #10 from gdr at cs dot tamu dot edu 2007-01-17 11:09 ---
Subject: Re: [regression] -Wconversion triggers warnings for
deque::push_back()
pcarlini at suse dot de [EMAIL PROTECTED] writes:
| Gaby, any news about the signed - unsigned warning itself? Are we going to
| keep
--- Comment #9 from msvoboda at ra dot rockwell dot com 2007-01-17 11:12
---
Created an attachment (id=12913)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12913action=view)
preprocessed file
I crossed this error too. I'm attaching required preprocessed file.
This bug occured
--- Comment #6 from dcb314 at hotmail dot com 2007-01-17 12:14 ---
(In reply to comment #5)
I can confirm this problem on recent snapshots as well (20070105 and
20070112).
Agreed.
Snapshot 20010112 goes wrong and it's definately the flag
--with-cpu=opteron that causes the trouble.
I just tried to compile package FlightGear-0.9.10-40
with the GNU C++ compiler version 4.3 snapshot 20070112.
The compiler said
replay.cxx: In function 'FGReplayData interpolate(double, FGReplayData,
FGReplayData)':
replay.cxx:224: internal compiler error: Segmentation fault
Please submit a full
--- Comment #1 from dcb314 at hotmail dot com 2007-01-17 12:17 ---
Created an attachment (id=12914)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12914action=view)
gzipped C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30490
--- Comment #20 from tromey at gcc dot gnu dot org 2007-01-17 12:32 ---
The particularity of such expressions is that they are constants.
I've thought about this a bit but I don't have a real conclusion.
I don't know why this warning was added in the first place... it seems
like
--- Comment #11 from ubizjak at gmail dot com 2007-01-17 12:39 ---
(In reply to comment #10)
What glibc version do you have? And what platform are you building on?
GNU C Library development release version 2.3.6
2.6.17-1.2142_FC4smp on i686-pc-linux-gnu and x86_64-pc-linux-gnu.
Checked this with gcc-3.4.6 and gcc 4.1.2 on an ubuntu edgy box.
[EMAIL PROTECTED]:~/try/bug$ cat makefile
all:
gcc-3.4 -c main.c -o obj-c/main.o -MMD -MF obj-c/main.d
gcc-3.4 -E main.c -o obj-E/main.i -MMD -MF obj-E/main.d
diff obj-c/main.d obj-E/main.d
[EMAIL
--- Comment #21 from gdr at cs dot tamu dot edu 2007-01-17 13:47 ---
Subject: Re: unsigned warning in template
tromey at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| The particularity of such expressions is that they are constants.
|
| I've thought about this a bit but I don't
--- Comment #2 from manu at gcc dot gnu dot org 2007-01-17 13:47 ---
Perhaps Wundefined should warn for PR 29465 ?
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from manu at gcc dot gnu dot org 2007-01-17 13:49 ---
Also, not sure whether Wundefined or Wsequence-points should handle PR 24016.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-17 13:52 ---
Another candidate is PR 30457.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #9 from felix-gcc at fefe dot de 2007-01-17 13:55 ---
Hey Andrew, do you really think this issue goes away if you keep closing the
bugs fast enough?
Let me tell you something: that INT_MAX way to do it is bogus. These checks
are there so that it is obvious the int overflow
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-17 13:56 ---
Unfortunately I still haven't been able to reproduce this.
I do have a few questions:
I'd like to see more of the build log, in particular what happened
before the failing command.
Does the failing gcj invocation
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-17 14:00 ---
Not so sure about this one PR 12411
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #6 from manu at gcc dot gnu dot org 2007-01-17 14:04 ---
Not sure about this one either, there seems to be a warning in C++ but I am not
sure what option controls it now: PR 30368.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #7 from gdr at cs dot tamu dot edu 2007-01-17 14:06 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Perhaps Wundefined should warn for PR 29465 ?
Where feasable with minimum overhead, yes.
-- Gaby
--
--- Comment #8 from gdr at cs dot tamu dot edu 2007-01-17 14:08 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Also, not sure whether Wundefined or Wsequence-points should handle PR 24016.
unspecified beahviour is not the same as
--- Comment #9 from gdr at cs dot tamu dot edu 2007-01-17 14:09 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Another candidate is PR 30457.
agreed.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30334
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-17 14:11 ---
Expected: As elemental procedures are also allowed, a case
EXEC_ASSIGN_CALL:
has to be added.
This is the easy bit... You then get:
$ /irun/bin/gfortran pr30407.f90
pr30407.f90: In function 'MAIN__':
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-01-17 14:26
---
You need to improve your communication skills - pissing people off doesn't help
your agenda. Btw, pointer overflow is undefined and we use that fact.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #10 from gdr at cs dot tamu dot edu 2007-01-17 14:26 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Not so sure about this one PR 12411
order of evaluation is unspecified, should go under the
sequence-points umbrella.
--- Comment #11 from gdr at cs dot tamu dot edu 2007-01-17 14:29 ---
Subject: Re: Request for -Wundefined
manu at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Not sure about this one either, there seems to be a warning in C++
| but I am not sure what option controls it now: PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2007-01-17 14:31
---
Btw. your testcase fails with gcc 2.95.3 for me as well, so no news here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #12 from felix-gcc at fefe dot de 2007-01-17 15:21 ---
(In reply to comment #11)
Btw. your testcase fails with gcc 2.95.3 for me as well, so no news here.
Bullshit.
$ ./gcc2 -v
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.3/specs
gcc version 2.95.3
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-01-17 15:35 ---
There are a few issues, first we use emit_libcall_block to emit the trapping
PLUS
which sets a REG_EQUAL note with a non-trapping PLUS.
Second we analyze iaddv as not possibly throwing so we remove the call from
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-01-17 16:32
---
[EMAIL PROTECTED]:/tmp /space/rguenther/install/gcc-2.95/bin/gcc -o int int.c
-O
[EMAIL PROTECTED]:/tmp ./int
200 100
-2147483549 2147483647
stock 2.95.3 sources. Don't tell people words, it makes you look like
--- Comment #14 from felix-gcc at fefe dot de 2007-01-17 16:37 ---
1. apologist, in contrast to asshole, is not a cuss word. Apparently you
are as ignorant about English as you are about the issue at hand.
2. I showed my gcc -v, why don't you? Maybe it's platform dependent? For all
--- Comment #15 from erdgeist-gcc at erdgeist dot org 2007-01-17 16:54
---
(In reply to comment #11)
Btw. your testcase fails with gcc 2.95.3 for me as well, so no news here.
Putting your struggles here aside, I'd like to see a type-agnostic assert from
you C-cracks to use for my
--- Comment #16 from pinskia at gcc dot gnu dot org 2007-01-17 16:56
---
http://c-faq.com/misc/sd26.html is all I am going to say from now on. It tell
you explictly how to dectect an overflow before an overflow is going to happen.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from sje at cup dot hp dot com 2007-01-17 16:58 ---
The code in comment #5 works fine. In pure C cases, if a prototype has been
seen when you get to the call, the floating point value goes into a FP reg. If
you haven't seen a prototype then the value goes into both an
--- Comment #17 from felix-gcc at fefe dot de 2007-01-17 17:02 ---
You misunderstand.
We don't want you to say anything.
We want to you make your optimization off by default, or remove it
altogether.
You could also try to convince us that there is any actual tangible performance
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-01-17 17:05
---
There is no single change that led to this situation and reverting it from
current development sources will not satisfy you anyway because old versions
are then still affected.
The correct way to test for this
There are
alpha/elf.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN)
\
alpha/unicosmk.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(STREAM,SYMREF) \
arm/aof.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(STREAM,SYMREF)\
cris/aout.h:#define ASM_OUTPUT_EXTERNAL_LIBCALL(FILE, FUN) \
--- Comment #19 from pinskia at gcc dot gnu dot org 2007-01-17 17:12
---
Again your code is broken to the standard and the comp.lang.c faq mentions a
way to not dependent on the undefined code so this again is not really a bug.
The question about security is what do you trust, the
--- Comment #6 from orion at cora dot nwra dot com 2007-01-17 17:14 ---
Sorry, Fedora libmpfr packaging bug
--
orion at cora dot nwra dot com changed:
What|Removed |Added
--- Comment #20 from amacleod at redhat dot com 2007-01-17 17:14 ---
Perhaps comment #12 and comment #13 would have the same results if they both
used the same options? One has -O and the other does not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #21 from felix-gcc at fefe dot de 2007-01-17 17:20 ---
I DID NOT WRITE THE BROKEN CODE.
Trying to trivialize the issue or insult me will not make it go away.
So, please tell me, which part of the argument in comment #9 were you unable to
follow? I could try using less
--- Comment #3 from patchapp at dberlin dot org 2007-01-17 17:20 ---
Subject: Bug number PR 17947
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/2007-01/msg01439.html
--
--- Comment #1 from patchapp at dberlin dot org 2007-01-17 17:21 ---
Subject: Bug number PR30465
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/2007-01/msg01440.html
--
The following C code demonstrates incorrect results when any optimization
is used:
#include stdio.h
#include stdlib.h
#include string.h
#include complex.h
#include math.h
struct fs {
int order;
int numpoles;
unsigned int polemask;
complex data[100];
};
void
--- Comment #3 from pault at gcc dot gnu dot org 2007-01-17 17:33 ---
Subject: Bug 30476
Author: pault
Date: Wed Jan 17 17:33:35 2007
New Revision: 120860
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120860
Log:
2007-01-17 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-01-17 17:42
---
(In reply to comment #21)
I DID NOT WRITE THE BROKEN CODE.
But you wrote the bug so I assumed you wrote it.
Trying to trivialize the issue or insult me will not make it go away.
How about this has not changed
--- Comment #9 from trt at acm dot org 2007-01-17 18:15 ---
I made lvalue_p a global function in my personal gcc.
I've proposed a dozen different warnings-related things for gcc, and never made
headway on any of them. I'm just a random user and don't know the secret
handshake. The
--- Comment #23 from felix-gcc at fefe dot de 2007-01-17 18:23 ---
In earlier gcc versions this only happened if the optimizer was on. So your
argument might hold some water there, if I squint my eyes enough.
But gcc 4.1 removes that code even with the optimizer turned off.
There
--- Comment #4 from pault at gcc dot gnu dot org 2007-01-17 18:33 ---
Subject: Bug 30476
Author: pault
Date: Wed Jan 17 18:33:35 2007
New Revision: 120864
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120864
Log:
2007-01-17 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2007-01-17 18:38 ---
Fixed on trunk and 4.2.
Thanks for the report!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-17 18:39 ---
I read through the existing code here and I think it is subtly correct.
The default_compilers array has a final entry consisting of all zeroes:
/* Mark end of table. */
{0, 0, 0, 0, 0}
'compilers' is
--- Comment #24 from pinskia at gcc dot gnu dot org 2007-01-17 18:43
---
Try doing some timings with and without -fwrapv and see what happens for normal
code.
You will see that without -fwrapv code runs faster.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475
--- Comment #25 from felix-gcc at fefe dot de 2007-01-17 19:04 ---
Well, duh. You removed the security checks.
Hey, I have one for you, too. Optimize away all calls to pthread_mutex_lock,
and lo and behold, multithreaded code will be much faster! It will also be
broken, but
--- Comment #10 from manu at gcc dot gnu dot org 2007-01-17 19:12 ---
I am also new, my first patch was just a few months ago, so let me say that I
understand your situation. On the other hand, I got patches committed, so also
let me say that it is not as bad as you may think.
The
--- Comment #33 from mrs at apple dot com 2007-01-17 19:13 ---
I think 4.2 would be a better release with this patch in it, could we push this
into 4.2, thanks. Any concerns about the satefy of the patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29516
--- Comment #26 from pinskia at gcc dot gnu dot org 2007-01-17 19:17
---
(In reply to comment #25)
Well, duh. You removed the security checks.
Which were wrong to begin with, See the comp.lang.c faq.
Hey, I have one for you, too. Optimize away all calls to pthread_mutex_lock,
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-01-17 19:44
---
Subject: Bug 27107
Author: fxcoudert
Date: Wed Jan 17 19:44:00 2007
New Revision: 120869
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120869
Log:
PR libfortran/27107
* runtime/environ.c:
--- Comment #7 from patchapp at dberlin dot org 2007-01-17 19:46 ---
Subject: Bug number PR 30437
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/2007-01/msg01456.html
--
--- Comment #1 from fang at csl dot cornell dot edu 2007-01-17 20:39
---
The problem with passing -E -o ... is that gcc has to assume the default output
object as the target, which strips the directory from the name, since -o is
used for the resulting .i file. That is what -MT is for,
--- Comment #34 from bergner at gcc dot gnu dot org 2007-01-17 20:58
---
Created an attachment (id=12915)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12915action=view)
Patch to commutative_operand_precedence to increase the precedence of
REG_POINTER and MEM_POINTER objects.
--- Comment #5 from tromey at gcc dot gnu dot org 2007-01-17 22:15 ---
Subject: Bug 27107
Author: tromey
Date: Wed Jan 17 22:14:48 2007
New Revision: 120878
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120878
Log:
PR libgfortran/27107:
* aclocal.m4, configure,
--- Comment #31 from echristo at gcc dot gnu dot org 2007-01-17 23:30
---
Subject: Bug 29302
Author: echristo
Date: Wed Jan 17 23:30:30 2007
New Revision: 120884
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120884
Log:
2007-01-17 Eric Christopher [EMAIL PROTECTED]
--- Comment #34 from howarth at nitro dot med dot uc dot edu 2007-01-17
23:38 ---
Also as the gfortran developers have pointed out, this bug is currently has a
target milestone 4.2.0 which implies it was intended to be fixed in gcc 4.2
branch as well. Unfortunately, I am having trouble
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2007-01-18
02:32 ---
What target milestone is this bug? If it is meant to be 4.2.0, shouldn't the
missing section of the original patch be applied to gcc 4.2 branch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30222
--- Comment #36 from gdr at gcc dot gnu dot org 2007-01-18 02:37 ---
A fix is not going to happen for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from gdr at gcc dot gnu dot org 2007-01-18 02:39 ---
Not to be fixed in GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #13 from gdr at gcc dot gnu dot org 2007-01-18 02:48 ---
Closing as fixed in recent version of GCC.
Not to be fixed in GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #46 from gdr at gcc dot gnu dot org 2007-01-18 02:51 ---
Won't fix for 4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13726
--- Comment #9 from gdr at gcc dot gnu dot org 2007-01-18 02:52 ---
Not to be fixed in GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #20 from gdr at gcc dot gnu dot org 2007-01-18 02:54 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #12 from gdr at gcc dot gnu dot org 2007-01-18 02:55 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #21 from gdr at gcc dot gnu dot org 2007-01-18 02:56 ---
Fixed in GCC-4.1.x.
Won't fix in GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from gdr at gcc dot gnu dot org 2007-01-18 02:57 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #17 from gdr at gcc dot gnu dot org 2007-01-18 02:58 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:00 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.1.2 |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16194
--- Comment #9 from gdr at gcc dot gnu dot org 2007-01-18 03:01 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #16 from gdr at gcc dot gnu dot org 2007-01-18 03:03 ---
won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #16 from gdr at gcc dot gnu dot org 2007-01-18 03:04 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:05 ---
won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #32 from gdr at gcc dot gnu dot org 2007-01-18 03:06 ---
No fix will happen for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #24 from gdr at gcc dot gnu dot org 2007-01-18 03:07 ---
No fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #30 from gdr at gcc dot gnu dot org 2007-01-18 03:09 ---
Fixed in GCC-4.1.0.
Not to be fixed in GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from gdr at gcc dot gnu dot org 2007-01-18 03:11 ---
Won't fix for GCC-4.0.x
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18631
--- Comment #13 from gdr at gcc dot gnu dot org 2007-01-18 03:13 ---
Fixed in GCC-4.1.0 and later.
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from gdr at gcc dot gnu dot org 2007-01-18 03:35 ---
won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:36 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #6 from gdr at gcc dot gnu dot org 2007-01-18 03:36 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #7 from gdr at gcc dot gnu dot org 2007-01-18 03:37 ---
won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #3 from gdr at gcc dot gnu dot org 2007-01-18 03:38 ---
Won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:39 ---
Fixed in 4.1.0.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from gdr at gcc dot gnu dot org 2007-01-18 03:40 ---
Fixed in 4.1.0.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #19 from gdr at gcc dot gnu dot org 2007-01-18 03:41 ---
won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #3 from gdr at gcc dot gnu dot org 2007-01-18 03:42 ---
won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from gdr at gcc dot gnu dot org 2007-01-18 03:43 ---
Fixed in 4.1.0.
won't fix in 4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from gdr at gcc dot gnu dot org 2007-01-18 03:45 ---
Fixed in GCC-4.1.1 and above.
Won't fix in GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #21 from gdr at gcc dot gnu dot org 2007-01-18 03:46 ---
won't fix for GCC-4.0.x
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
--- Comment #10 from gdr at gcc dot gnu dot org 2007-01-18 03:46 ---
won't fix for GCC-4.0.x.
--
gdr at gcc dot gnu dot org changed:
What|Removed |Added
Target
1 - 100 of 113 matches
Mail list logo
