--- Comment #8 from patchapp at dberlin dot org 2006-07-06 06:45 ---
Subject: Bug number PR28187
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-07/msg00195.html
--
http://gcc.gnu.org/bugzilla/sh
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #6 from jason at gcc dot gnu dot org 2006-07-06 03:48 ---
Hmm, actually comment #2 does seem like a bug, both foos should compile
cleanly.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from jason at gcc dot gnu dot org 2006-07-06 03:45 ---
f1x0r'd
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from patchapp at dberlin dot org 2006-07-06 03:45 ---
Subject: Bug number PR27898
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-07/msg00187.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #12 from jason at gcc dot gnu dot org 2006-07-06 03:44 ---
feexd
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from jason at gcc dot gnu dot org 2006-07-06 03:33 ---
Subject: Bug 13983
Author: jason
Date: Thu Jul 6 03:33:20 2006
New Revision: 115220
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115220
Log:
PR c++/13983
PR c++/17519
* stor-layout.
--- Comment #17 from jason at gcc dot gnu dot org 2006-07-06 03:33 ---
Subject: Bug 17519
Author: jason
Date: Thu Jul 6 03:33:20 2006
New Revision: 115220
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115220
Log:
PR c++/13983
PR c++/17519
* stor-layout.
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-06 03:08 ---
Confirmed, at least a 4.1/4.2 regression, I cannot test 4.0.x but I do know
that "4.1.0 20051026" worked and so did "4.0.0 20050225".
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #16 from jason at gcc dot gnu dot org 2006-07-06 02:21 ---
Subject: Bug 17519
Author: jason
Date: Thu Jul 6 02:21:17 2006
New Revision: 115219
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115219
Log:
PR c++/13983
PR c++/17519
* stor-layout.
--- Comment #10 from jason at gcc dot gnu dot org 2006-07-06 02:21 ---
Subject: Bug 13983
Author: jason
Date: Thu Jul 6 02:21:17 2006
New Revision: 115219
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115219
Log:
PR c++/13983
PR c++/17519
* stor-layout.
--- Comment #29 from jason at gcc dot gnu dot org 2006-07-06 02:15 ---
feexd
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #15 from jason at gcc dot gnu dot org 2006-07-06 02:09 ---
Subject: Bug 17519
Author: jason
Date: Thu Jul 6 02:09:02 2006
New Revision: 115217
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115217
Log:
PR c++/13983
PR c++/17519
* stor-layout.
--- Comment #9 from jason at gcc dot gnu dot org 2006-07-06 02:09 ---
Subject: Bug 13983
Author: jason
Date: Thu Jul 6 02:09:02 2006
New Revision: 115217
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115217
Log:
PR c++/13983
PR c++/17519
* stor-layout.c
--- Comment #17 from dannysmith at users dot sourceforge dot net
2006-07-06 01:06 ---
On mingw32 the testcase will succeed on trunk if libstdc++ (and libgcc) are
built as dlls. Wouldn't that be the preferred solution? It also solves very
similar problems with EH data.
Danny
--
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-07-06 00:57
---
> Perhaps it doesn't ICE on the 4.1 branch only because release branches don't
> have checking enabled?
All the compilers I use for testing were configured with --enable-checking
- even GCC 2.95.3 ;).
Which means
--- Comment #8 from tromey at gcc dot gnu dot org 2006-07-06 00:19 ---
It is PR 19505.
The patch is:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00425.html
I've been meaning to test this but haven't had a chance yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28222
--- Comment #7 from tromey at gcc dot gnu dot org 2006-07-06 00:16 ---
I've seen this too... there's some other PR with a proposed
patch by Andrew Haley. I forget the number -- I'll try to find it later.
I don't recall why I'm not seeing it right now.
Perhaps because I'm building with -
--- Comment #6 from tromey at gcc dot gnu dot org 2006-07-06 00:05 ---
Any word on this?
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|
This is an internal reminder for the issue pointed out by Martin in:
c++std-lib-17244
It looks like, we are implementing the current C++ specifications rather well,
besides a few issues. See the test:
http://people.apache.org/~sebor/width_test.cpp
--
Summary: formatted I/O and
--- Comment #7 from pcarlini at suse dot de 2006-07-05 23:17 ---
Humm, at least the various instances of the problem related to padding seem
simple to fix, by just doing the I/O as part of the padding itself - it's *the
last* stage of the processing anyway...
--
http://gcc.gnu.org/b
--- Comment #1 from danglin at gcc dot gnu dot org 2006-07-05 23:09 ---
This test stopped failing at some point after July 2, 18:06:02 UTC 2006
(r115133).
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
||do
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #6 from pcarlini at suse dot de 2006-07-05 22:48 ---
(In reply to comment #5)
> The threads point is just a basic stack size issue: threads on linux have a
> fixed size which is often smaller than the main stack size limit.
Ok then.
> With an output width of 60 million, it'
--- Comment #5 from mec at google dot com 2006-07-05 22:43 ---
The threads point is just a basic stack size issue: threads on linux have a
fixed size which is often smaller than the main stack size limit.
With an output width of 60 million, it's easy to see a failure, even on a main
sta
--- Comment #4 from pcarlini at suse dot de 2006-07-05 22:32 ---
(In reply to comment #2)
> Sure, here is a test program for versa_string:
Ok, the stack thing is rather straightforward but of course we should first dig
the archives and find when and why, **a lot** of time ago, such uses
--- Comment #3 from pinskia at physics dot uc dot edu 2006-07-05 22:27
---
Subject: Re: __builtin_alloca with no limit in libstdc++
>
>
> std::cout.width(6000);
> This program allocates 60 million bytes on the stack in the last output
> statement.
You get what you deserve rea
>
>
> std::cout.width(6000);
> This program allocates 60 million bytes on the stack in the last output
> statement.
You get what you deserve really. If there are checks then it will be slow.
-- Pinski
--- Comment #2 from mec at google dot com 2006-07-05 22:20 ---
Sure, here is a test program for versa_string:
// Copyright 2006, Google Inc. All rights reserved.
// Author: [EMAIL PROTECTED] (Michael Chastain)
//
// Test operator<<(ostream&, const versa_string&)
#include
#include
--- Comment #2 from kargl at gcc dot gnu dot org 2006-07-05 21:53 ---
Confirmed.
I have a patch, but it may depend on MPFR 2.2.0.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2006-07-05 21:47 ---
(In reply to comment #0)
> These have data-dependent sizes with no obvious limit, which does not mix well
> with threads and small stacks.
I suppose you are going to provide additional details...
--
http://gcc.gnu.or
libstc++ uses __builtin_alloca in several places:
config/local/gnu/codecvt_members.cc
include/ext/codecvt_specializations.h
include/ext/vstring.cc
include/bits/locale_facets.tcc
include/bits/ostream.tcc
include/bits/fstream.cc
include/std/std_valarray.h
src/valarray-inst.cc
These
--- Comment #28 from jason at gcc dot gnu dot org 2006-07-05 20:40 ---
Subject: Bug 18681
Author: jason
Date: Wed Jul 5 20:40:49 2006
New Revision: 115210
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115210
Log:
PR c++/18681
* friend.c (is_friend): Fix DR 45 i
--- Comment #27 from jason at gcc dot gnu dot org 2006-07-05 20:40 ---
Subject: Bug 18681
Author: jason
Date: Wed Jul 5 20:40:06 2006
New Revision: 115209
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115209
Log:
PR c++/18681
* friend.c (is_friend): Fix DR 45 i
--- Comment #5 from jason at gcc dot gnu dot org 2006-07-05 20:38 ---
This is intended behavior: a non-POD type which has been marked as packed can
be used as a packed field. 13983 and 17519 are bugs in that feature.
In this case, nonpod_pack::n is not packed, so it is safe to pack fie
--- Comment #7 from janis at gcc dot gnu dot org 2006-07-05 20:35 ---
Regression tests using the reduced testcase from comment #3 on mainline for
powerpc-linux identified this patch where the test starts failing:
http://gcc.gnu.org/viewcvs?view=rev&rev=103604
r103604 | mmitchel
--- Comment #7 from dje at gcc dot gnu dot org 2006-07-05 20:03 ---
I think this simply is a case of not allowing TFmode in PRE_INC addresses:
Index: rs6000.c
===
--- rs6000.c(revision 115196)
+++ rs6000.c(working c
--- Comment #1 from anlauf at gmx dot de 2006-07-05 20:01 ---
Created an attachment (id=11838)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11838&action=view)
Example code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28276
Hi *,
there is a nasty bug with EXPONENT():
EXPONENT(1.0) evaluates to 0 (which is wrong), while
real :: a=1.0; EXPONENT(a) evaluates to 1 (which is correct).
For more details and a further example see the attached
code sample.
Cheers,
-ha
--
Summary: EXPONENT() broken for real con
--- Comment #26 from jason at gcc dot gnu dot org 2006-07-05 19:44 ---
Subject: Bug 18681
Author: jason
Date: Wed Jul 5 19:44:28 2006
New Revision: 115208
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115208
Log:
PR c++/18681
* friend.c (is_friend): Fix DR 45 i
--- Comment #2 from apl at alum dot mit dot edu 2006-07-05 19:16 ---
Ideally, this should not produce an error UNLESS you invoke
derived::upcast()
from within a compilation unit under the influence of -fno-rtti
--
apl at alum dot mit dot edu changed:
What|Removed
--- Comment #1 from apl at alum dot mit dot edu 2006-07-05 19:15 ---
Created an attachment (id=11836)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11836&action=view)
test generating error
compile with
g++ -fno-rtti
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28275
A template class containing any use of dynamic_cast<> results in an error
GenericDigraph.h:95: error: 'dynamic_cast' not permitted with -fno-rtti
even when the template is not instantiated!
--
Summary: Error compiling template class containing dynamic_cast<>
with
--- Comment #8 from apl at alum dot mit dot edu 2006-07-05 19:08 ---
Created an attachment (id=11835)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11835&action=view)
protection against dynamic_cast<> with -fno-rtti is too eager
Here's a test that NEVER instantiates the template,
--- Comment #5 from patchapp at dberlin dot org 2006-07-05 18:55 ---
Subject: Bug number PR fortran/27698
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-07/msg00159.html
--
http://gcc.gnu.org/bu
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-07-05 18:54 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #7 from apl at alum dot mit dot edu 2006-07-05 18:50 ---
I think that this fix may have been too aggressive. I have a templated class
with a member function that does a dynamic_cast<>. With 4.2, I'm getting
errors when
I compile this template, despite the fact that I don't
--- Comment #8 from hjl at gcc dot gnu dot org 2006-07-05 18:49 ---
Subject: Bug 26146
Author: hjl
Date: Wed Jul 5 18:49:48 2006
New Revision: 115206
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115206
Log:
2006-07-05 H.J. Lu <[EMAIL PROTECTED]>
PR target/26146
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-05 18:41 ---
3.4.0 did not ICE with checking disabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26938
--- Comment #3 from jason at gcc dot gnu dot org 2006-07-05 18:29 ---
Perhaps it doesn't ICE on the 4.1 branch only because release branches don't
have checking enabled?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27397
bash-2.05b$ cat defarg.C
int f (int i, int j = 0);
int f (int i = 0, int j);
bash-2.05b$ ./cc1plus defarg.C -quiet
defarg.C:2: error: default argument missing for parameter 2 of int f(int,
int)
defarg.C:2: error: default argument given for parameter 2 of int f(int, int)
defarg.C:1: error: afte
--- Comment #5 from dtemirbulatov at gmail dot com 2006-07-05 18:26 ---
> It should instead issue the warning "statement is a reference, not call, to
> function A::f"
gcc producing the warnig, if you using -Wall flag
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26696
--- Comment #3 from jason at gcc dot gnu dot org 2006-07-05 18:19 ---
added known to work in 3.3.6
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #18 from jason at gcc dot gnu dot org 2006-07-05 18:03 ---
Removing the 4.2 regression tag, since apparently it's fixed there. I'm not
sure how this qualifies as a regression at all, since the bug was reported
against 3.4 and there's no report of it working better with a pre
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-07-05 18:00
---
68K is not release-critical.
However, Paul, would you please look into this, as Andreas believes this to be
caused by your change?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-07-05 17:59
---
(In reply to comment #15)
> Not release-critical until we have evidence that this is not Fortran-specific.
Mark,
Did you miss comment #6 which shows the bug in C code?
Yes there were a lot of comments thinking it
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-07-05 17:59
---
We should understand if there was an intentional ABI change.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-07-05 17:57
---
Ada is not release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-07-05 17:56
---
Ada/OSF not release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from mmitchel at gcc dot gnu dot org 2006-07-05 17:56
---
Not release-critical until we have evidence that this is not Fortran-specific.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26968
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26658
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23305
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-07-05 17:44
---
Java bugs are not release-critical. If, however, this is coming from CNI code,
then please move this back to P3, and I will re-review. It would be nice to
have a description of what's wrong with the debug output.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21507
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20826
--- Comment #4 from sgk at troutmask dot apl dot washington dot edu
2006-07-05 17:35 ---
Subject: Re: subroutine _foo draws "unclassifiable statement" instead of a
useful error.
On Wed, Jul 05, 2006 at 05:19:44PM -, aldot at gcc dot gnu dot org wrote:
>
>
> --- Comment #3 fr
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-07-05 17:31 ---
*** Bug 28273 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-05 17:31 ---
*** This bug has been marked as a duplicate of 26504 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from aldot at gcc dot gnu dot org 2006-07-05 17:19 ---
(In reply to comment #2)
> Bernhard,
>
> Your patch only addresses one aspect of the problem.
> Consider
>
> function _foo
> entry _bar
> end function
>
Is it sufficient to print an error in gfc_match_name, or s
--- Comment #3 from pluto at agmk dot net 2006-07-05 17:06 ---
(In reply to comment #2)
> When you file a bug about bootstrap failure, can you the following
> information:
> How you configured?
Reading specs from ./specs
Target: ppc-pld-linux
Configured with: ../configure --prefix=/usr
gcc 4.1.1 fails to make with the following configure command:
from inside a custom directory avrobj created in gcc-4.1.1:
../configure --target=avr --prefix=/usr/local/avr --enable-languages=c
--with-elf --with-dwarf2 --with-stabs --disable-libssp --disable-nls
message from make failure is:
../..
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-05 16:25 ---
Fixed.
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-07-05 16:25 ---
Subject: Bug 28158
Author: rguenth
Date: Wed Jul 5 16:24:57 2006
New Revision: 115203
URL: http://gcc.gnu.org/viewcvs?root=
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-05 16:25 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-07-05 16:09 ---
VRP relies on pointer equivalence in update_value_range, but we get
(gdb) call debug_generic_expr (var)
windowD.1282_5
(gdb) print *old_vr
$11 = {type = VR_RANGE, min = 0xb7ce93c0, max = 0xb7cf0678, equiv = 0x88c69a
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-07-05 16:04 ---
The ICE was exposed by:
2006-05-27 Richard Guenther <[EMAIL PROTECTED]>
PR middle-end/27773
* fold-const.c (fold_plusminus_mult_expr): Use fold_convert
to produce a constant of value 1 of g
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-07-05 15:57 ---
When you file a bug about bootstrap failure, can you the following information:
How you configured?
How did you invoke make?
What environment variable were set that could affect the options like CFLAGS?
--
http:
--- Comment #1 from pluto at agmk dot net 2006-07-05 15:53 ---
Created an attachment (id=11834)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11834&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28272
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-07-05 15:49 ---
Fixed. Modulo the problem being latent on 4.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-05 15:49 ---
Subject: Bug 28162
Author: rguenth
Date: Wed Jul 5 15:49:12 2006
New Revision: 115202
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115202
Log:
2006-07-05 Richard Guenther <[EMAIL PROTECTED]>
PR
--- Comment #6 from pluto at agmk dot net 2006-07-05 15:48 ---
(In reply to comment #5)
> with -O2 ./cc1 ICEs.
for more details see PR28272
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28264
(gdb) set args -fpreprocessed libgcc2.i -msecure-plt -quiet -dumpbase
libgcc2.c -auxbase-strip libgcc/./_mulvsi3.o -ggdb -O2 -O2 -O2 -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-version -fno-strict-aliasing -fwrapv -fsigned-char -fPIC -fvisibility=hidde
--- Comment #5 from pluto at agmk dot net 2006-07-05 15:45 ---
ok, my fault.(In reply to comment #4)
> ohhh, now I see what's wrong.
>
> Out of Memory: Killed process 18248 (cc1).
>
> the PPC970FX box has 1GB ram + 1GB swap.
> i'll re-run build and try to reproduce this memory-hog.
bo
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--
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=28269
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28270
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-07-05 15:25 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.1.2
Known to work||4.2.0
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2006-07-05 15:22
---
Subject: Bug 20892
Author: fxcoudert
Date: Wed Jul 5 15:22:26 2006
New Revision: 115201
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115201
Log:
PR fortran/20892
* interface.c (gfc_matc
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-07-05 15:20 ---
Slightly more reduced (for 4.1.2 on i686, trunk doesn't fail here):
extern void bar(int);
void checkgroups(int last, int verbose)
{
int window = 0;
int outstanding = 0;
while (window < last || outstandin
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-07-05 15:12 ---
Visiting statement:
window_6 = ASSERT_EXPR ;
)
(res = scev_not_known))
Found new range for window_6: [-INF, last_7 + -1]
Simulating statement (from ssa_edges): last_50 = ASSERT_EXPR ;
Visiting statement:
l
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-07-05 15:09
---
(In reply to comment #6)
> Andrew, what is the status on that bug? Do you still observe mismatch in the
> testsuite, or can we close the PR?
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25270
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-07-05 15:06 ---
Reduced testcase, -O -ftree-vrp -fwrapv
extern int foo(const char *);
extern int verbose;
struct newsgroup {
char* name;
};
extern struct newsgroup** stufftoget;
extern char *l;
void checkgroups(int last)
{
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28267
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28266
1 - 100 of 147 matches
Mail list logo
