--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-13
07:56 ---
Created an attachment (id=8884)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8884&action=view)
selected_int_kind.f90
As requested by Tobi, the selected_int_kind.f90 building h8300-rtems4.7
gcc-4.0.1
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-13
07:59 ---
Created an attachment (id=8885)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8885&action=view)
selected_int_kind.inc
Sorry, wrong file. This is the *.inc, Tobi requested.
--
http://gcc.gnu.org/b
I do not know if the following example is considered valid code. I do not have
a copy of the standard.
The following code fails with g++-3.4 (GCC) 3.4.4 20050314 (prerelease)
(Debian 3.4.3-12).
error messages:
test.cpp:28: error: invalid explicit specialization before '>
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-13
09:52 ---
The testcase is fine. We just optimize it no more with the STRIP_TYPE_NOPS
change. This change was to avoid stripping type qualifiers such as const
from lvalues - so we might need to use some other type st
--- Additional Comments From alexander_herrmann at yahoo dot com dot au
2005-05-13 09:53 ---
Subject: Re: 4.0/4.1 Regression __builtin_expect
Hi there,
> --- Additional Comments From pinskia at gcc dot
> gnu dot org 2005-05-12 12:12 ---
> Can you attached the preprocessed sour
binutils are installed into /opt/x86_64/binutils
gcc is configured as follow :
--target=x86_64-pc-linux-gnu
--host=i686-pc-linux-gnu
--enable-__cxa_atexit
--prefix=/opt/x86_64/gcc/3.4.3
--with-local-prefix=/var/x86_64
--with-newlib
--without-headers
--
--- Additional Comments From uros at kss-loka dot si 2005-05-13 10:07
---
I think there is another optimization opportunity regarding movzbl following
andl.
Consider this part:
movb(%eax), %alEAX = x...x
andl$1, %eax EAX = 0...
We fail in verify_ssa because
/net/pherkad/scratch/rguenth/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11:
error: Statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
# VUSE ;
ao.ch[2] = 0;
/net/pherkad/scratch/rguenth/gcc/gcc/testsuite/gcc.c-torture/execute/20031215-1.
When I compile the following file with 'gcc -O2 file.c' I get:
file.c: In function 'clip':
file.c:2: internal compiler error: in convert_move, at expr.c:339
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--- file.c ---
--- Additional Comments From menzel at ls6 dot cs dot uni-dortmund dot de
2005-05-13 10:16 ---
Oh, I forgot, here is the output of 'gcc -v':
Using built-in specs.
Target: sparc-sun-solaris2.9
Configured with: /home/menzel/src/4.0.0/gcc-4.0.0/configure
--prefix=/home/menzel/sw5.9-gcc4.0.
--
What|Removed |Added
Component|c |middle-end
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show
--- Additional Comments From alexander_herrmann at yahoo dot com dot au
2005-05-13 11:16 ---
Subject: Re: 4.0/4.1 Regression __builtin_expect
The promised Testcase. Earlier than expected :)
aie_sql_meta.c: In Funktion
ปaie_sql_meta_create_indexซ:
aie_sql_meta.c:32: Warnung: ปindex_ty
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
11:17 ---
Try instead using --disable-multilib, that will work instead.
also if you did not move the need_64bit_hwint=yes part to the 64bit part, then
you don't need to
change libcpp.
--
http://gcc.gnu.org/bugzi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
11:30 ---
Confirmed, stupid non-existent type system.
--
What|Removed |Added
Status|UNCONF
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
11:42 ---
The warning is correct for tableid and index_typ as this is an "or" expression.
So this is invalid.
If I change it to && then that is just PR 21513.
--
What|Removed |Ad
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21520
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21532
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
11:53 ---
No feedback in 3 months.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From alexander_herrmann at yahoo dot com dot au
2005-05-13 11:55 ---
Subject: Re: 4.0/4.1 Regression __builtin_expect
> The warning is correct for tableid and index_typ as
> this is an "or" expression.
if (__builtin_expect(((index_def == NULL) ||
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
11:55 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
12:00 ---
Then it is a dup of bug 21513.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21531
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-13
12:25 ---
Subject: Bug 20756
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-13 12:25:35
Modified files:
gcc: ChangeLog flow.c
Log message:
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
./configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol
--- Additional Comments From joseph at codesourcery dot com 2005-05-13
12:45 ---
Subject: Re: New: [4.1 regression]
gcc.c-torture/execute/20031215-1.c ICEs
On Fri, 13 May 2005, rguenth at gcc dot gnu dot org wrote:
>Summary: [4.1 regression] gcc.c-torture/execute/20031215
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
12:46 ---
I knew this was already opened.
*** This bug has been marked as a duplicate of 21541 ***
--
What|Removed |Added
-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
12:46 ---
*** Bug 21545 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-13
12:48 ---
See duplicate 21545 for (some) analysis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21541
--- Additional Comments From alexander_herrmann at yahoo dot com dot au
2005-05-13 13:06 ---
Subject: Re: 4.0/4.1 Regression __builtin_expect
Ok, than we move it into another catagory. Compiler
crashes with segmentation fault.
After 20 years of C programing it is like felling
feeling
--- Additional Comments From joseph at codesourcery dot com 2005-05-13
13:17 ---
Subject: Re: New: gcc 4.0.0 assumes all i386-pc-solaris2.10
platforms have 64-bit processors
On Fri, 13 May 2005, Daniel dot Davies at xerox dot com wrote:
> I've been trying to build GCC 4.0.0 on an ord
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
13:18 ---
Most of the problem is PR 17141, the other problem comes into play with struct
aliasing issues.
--
What|Removed |Added
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-13
13:34 ---
Subject: Bug 20756
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-13 13:34:19
Modified files:
gcc: basic-block.h
Log message:
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-05-13
13:37 ---
Fixed on mainline with check-in from today.
--
What|Removed |Added
Status|UNCONF
--
Bug 20695 depends on bug 20756, which changed state.
Bug 20756 Summary: Clobbers of deleted insns are processed, but left out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20756
What|Old Value |New Value
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20756
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-05-13
13:50 ---
An updated patch is here:
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01238.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20714
--- Additional Comments From hurbain at cri dot ensmp dot fr 2005-05-13
13:55 ---
I encountered this bug too with a very similar code on GCC 4.1 snapshot 20050424
with options -O2 -msse2 -ftree-vectorize.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21234
$ cat uninit.c
static int blocksize = 4096;
int bar (int);
void foo (void)
{
int toread;
int bytes;
static char eof_reached = 0;
toread = blocksize;
while (toread != 0)
{
bytes = bar (toread);
if (bytes <= 0)
{
if (bytes < 0)
It looks like people often have trouble finding the libstdc++-specific configure
options. It is suggested, very sensibly in my opinion, that the documentation
should be added to http://gcc.gnu.org/install/configure.html, in a specific
section - similarly to Fortran/Java(libgcj) and so on - or, mayb
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
14:53 ---
hmm, what happens if blocksize is zero when foo is entered.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21548
--- Additional Comments From schwab at suse dot de 2005-05-13 14:54 ---
The program logic guarantees that blocksize is never zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21548
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-13
14:57 ---
The compiler can't be expected to follow that logic. If blocksize is set to
zero by some magic daemon, then the bytes would be undefined.
--
What|Removed |Added
---
--- Additional Comments From schwab at suse dot de 2005-05-13 14:59 ---
To clarify, the problem is the "is used" part. This should be "might be used"
instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21548
--- Additional Comments From schwab at suse dot de 2005-05-13 15:00 ---
It is not _always_ uninitialized.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
15:01 ---
I also get the warning in 3.4.0 and 3.3.3 with your example, did you reduce it
too far?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21548
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-05-13
15:05 ---
It's nothing to do with ALWAYS. It's to do with COULD BE.
There are values that blocksize COULD take that would lead to bytes being
uninitialized. That's all the warning is telling you.
The compiler is
--- Additional Comments From schwab at suse dot de 2005-05-13 15:06 ---
That's why it should say "might be used".
--
What|Removed |Added
Status|RESOLVED
gcc 4.0.0 generates slower code than gcc 3.4.3 for the BLAS "axpy" operation.
(This is no doubt specific to IA32, and perhaps also to the processor version.)
The program is below, here are the timing results:
gcc 3.4.3gcc 4.0.0
Method cpu secs cpu secs
z[]=x
Hello,
I would like know if GCC compiler 2.95.3 could be
installed on Red Hat Entreprise Linux ES 3.0 and
recompile
C/C++ programs that were written/compiled earlier
using 2.95.3 GCC compiler on Sun Solaris V 2.6
machine.
Also would like to know the pros and cons in using GCC
2.95.3 in preferenc
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-13
16:30 ---
Could you write a reduced test case?
Ideally it would be in Mauve form; that way we can easily put it
in the test suite when we put in the fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524
As of Fri May 13 05:21:49 UTC 2005, gcc 4.0 failed to bootstrap on ia64:
./xgcc -B./ -B/usr/gcc-4.0/ia64-unknown-linux-gnu/bin/ -isystem
/usr/gcc-4.0/ia64-unknown-linux-gnu/include -isystem
/usr/gcc-4.0/ia64-unknown-linux-gnu/sys-include
-L/export/build/gnu/gcc-4.0/build-ia64-linux/gcc/../ld -O2
As of Fri May 13 05:21:49 UTC 2005, I got
stage1/xgcc -Bstage1/ -B/usr/gcc-4.1/ia64-unknown-linux-gnu/bin/ -c
-DUSE_LIBUNWIND_EXCEPTIONS -g -O2 -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
-Wno-variadic-macros -Wold-style-definition -Werr
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-13
16:56 ---
Subject: Bug 20793
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-13 16:56:12
Modified files:
gcc: ChangeLog bt-load.c integrate.c
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-13
16:56 ---
Subject: Bug 20769
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-13 16:56:12
Modified files:
gcc: ChangeLog bt-load.c integrate.c
Log
Here is what I did:
$ export GCC_EXEC_PREFIX=/my_prefix/lib/gcc/
$ gcc --print-search-dirs
install: /opt/gnu/gnat/lib/gcc/sparc-sun-solaris2.8/3.4.4/
programs: =
/libexec/gcc/sparc-sun-solaris2.8/3.4.4/:
/libexec/gcc/:
/opt/gnu/gnat/libexec/gcc/sparc-sun-solaris2.8/3.4.4/
libraries: =
/my_prefix/
--
What|Removed |Added
CC||roche at adacore dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-05-13
17:19 ---
Fixed on mainline with patch checked in today.
--
What|Removed |Added
Status|UNC
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-05-13
17:20 ---
Fixed on mainline with patch checked in today.
--
What|Removed |Added
Status|UNC
--- Additional Comments From schwab at suse dot de 2005-05-13 17:53 ---
I couldn't reproduce that, and I didn't see any regressions since yesterday.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21552
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
18:01 ---
Confirmed, --with-pic being documented would be very nice even though it is a
generic libtool
configure option, it is most used with libstdc++ as shown by the bug reports
about the using static
libstdc++
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
18:03 ---
I think this basically goes back to the correct selection of IVs and i386
addressing mode, aka a*4+b
and such, there are other bugs opened about that already.
--
What|Removed
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-05-13
18:20 ---
Sebastian, would you mind taking a look at this? It's assigned to me but it's
likely that you will be able to figure out what's going on in chrec more
quickly. And I won't have time to look at this for a
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-13
18:23 ---
Subject: Bug 20714
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-13 18:23:17
Modified files:
gcc: optabs.c ChangeLog
Log message:
--
Bug 20695 depends on bug 20714, which changed state.
Bug 20714 Summary: emit_no_conflict_block does invalid reordering
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20714
What|Old Value |New Value
---
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-05-13
18:30 ---
Fixed on mainline.
--
What|Removed |Added
Status|UNCONFIRMED |RE
--
What|Removed |Added
OtherBugsDependingO||20695
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20396
--
What|Removed |Added
BugsThisDependsOn||20396
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20695
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-13 18:48
---
(In reply to comment #9)
> Created an attachment (id=8885)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8885&action=view)
> selected_int_kind.inc
>
> Sorry, wrong file. This is the *.inc, Tobi requeste
The failure
FAIL: ext/array_allocator/2.cc execution test
appeared on 4.0 branch on hppa64-hpux with the patch
http://gcc.gnu.org/ml/gcc-cvs/2005-05/msg00433.html
2005-05-09 Benjamin Kosnik <[EMAIL PROTECTED]>
* docs/html/test.html: Update.
* testsuite/printnow.c: Remove.
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-13 19:25
---
Steve, are you saying that you're seeing the same failure on a Pentium 4
machine? This would be weird because ...
Ralf, it looks like no working integer type is found when building the
compiler.
I'm out o
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-13 19:27
---
What was the purpose of applying this patch to 4.0 branch? Did it fix a
regression? I can't find this patch (looking for the ChangeLog entry test) in
my gcc-patches folders.
As the patch changes the testsui
from c.l.c.moderated by Maxim Yegorushkin:
#include
namespace N {
#ifdef SHOW_BUG
struct A
{
};
int swap(A&, A&);
#else
struct A
{
friend int swap(A&, A&);
};
#endif
struct B : A
{
};
void swap(B& x, B& y)
{
using std::swap;
typedef char a[sizeof(swap(static_cast(x), sta
The patch
2005-05-11 Richard Henderson <[EMAIL PROTECTED]>
PR target/21412
* config/ia64/ia64.c (TARGET_CANNOT_FORCE_CONST_MEM): New.
(ia64_cannot_force_const_mem): New.
[...]
causes mainline bootstrap to fail on ia64-hpux. The failure is when building
libgcc w
--- Additional Comments From rth at gcc dot gnu dot org 2005-05-13 19:43
---
Well, since it works on ia64-linux, you'll have to give me more information.
I assume I'm failing to addp4 in the right place, or something...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21556
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-05-
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-13
20:10 ---
One workaround is not to use -O2.
My current guess is that a fold-based optimization creates
a tree that the bytecode generator does not understand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21519
In some circumstances, calling Thread.interrupt() will result in
_Jv_MonitorEnter entering an infinite loop. This is because _Jv_MonitorEnter
uses _Jv_CondWait, which is interruptable, without checking the return value.
There are more details in this thread:
http://gcc.gnu.org/ml/java/2005-05/ms
--- Additional Comments From pcarlini at suse dot de 2005-05-13 20:16
---
Given our current basic_string implementation (which I'm maintaining) I can
tell you that this testcase is very brittle: see 19495, that lead to the
xfail for powerpc, for additional details. Benjamin's changes can
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-13
20:17 ---
Reduced test case
public class reduce {
char[] source;
public int compute(int pos) {
for (int i = 0; i < pos; ++i)
if (!(source[i] == ' ' || source[i] == '\t')) return -1;
return pos;
}
}
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
20:34 ---
(In reply to comment #11)
> Steve, are you saying that you're seeing the same failure on a Pentium 4
> machine? This would be weird because ...
Steve, I have heard that there are some GMP with bugs which
--- Additional Comments From joseph at codesourcery dot com 2005-05-13
20:39 ---
Subject: Re: [4.0 Regression] ext/array_allocator/2.cc
execution test fails on hppa64-hpux
On Fri, 13 May 2005, pcarlini at suse dot de wrote:
> Given our current basic_string implementation (which I'm m
GCC's optimizer is able to partially unroll a recursive function. As one might
expect, this causes some code duplication. You get several unrolled copies of
the code before the recursive call, then the recursive call itself, and then
several unrolled copies of the code after the recursive call.
--- Additional Comments From liblit at cs dot wisc dot edu 2005-05-13
20:51 ---
Created an attachment (id=8886)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8886&action=view)
preprocessed C code exhibiting the bug
The code in "redundant.i" shows the problem as described earlier.
--- Additional Comments From pcarlini at suse dot de 2005-05-13 21:13
---
> So this should be treated as a known latent bug, a testcase which fails or
> passes at random on targets requiring strict alignment? In which case
> there should be an effective-target keyword for strict align
--- Additional Comments From Daniel dot Davies at xerox dot com 2005-05-13
21:18 ---
Thank you both for your helpful comments. My big mistake was not going to the
gcc site for the updated configuration instructions when my build wasn't going
well. Configuring the build as described in
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-13
21:24 ---
I submitted a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |
--- Additional Comments From kargl at gcc dot gnu dot org 2005-05-13 21:30
---
Tobi and Andrew, Yes, I see this exact failure on FreeBSD with
a pentium 4 M processor. I spent a few days hacking on Makefiles
to turn on/off different compiler options and could never resolve
the issues.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
21:42 ---
I don't see what is wrong with the generated code, maybe a dead store.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
21:44 ---
Oh, I see the dead stores now in 4.0.0, this was fixed in 4.1.0 by fixing up
DSE.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
21:54 ---
In 4.1.0, we give:
t.c:8: warning: bytes may be used uninitialized in this function
So this is only a 4.0.0 bug, let me see how it is considered as "is used".
--
What|Removed
--- Additional Comments From liblit at cs dot wisc dot edu 2005-05-13
22:01 ---
Sorry for not trying this on a more recent snapshot first. Thanks for the quick
resolution, Andrew. I'm very glad to hear this problem has already been fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
22:14 ---
Actually rethinking the problem, the only time we could execute the "if(bytes
== 0)" is not going
through the loop. Maybe the order in execute_late_warn_uninitialized should be
switched around but
that
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
22:16 ---
Maybe not. Hmm, there might be a wrong code bug here on the 4.0 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21548
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
22:23 ---
thinking again out loud:
The function could be changed to (which we seem to be missing on the mainline):
static int blocksize = 4096;
int bar (int);
void foo (void)
{
int toread;
int bytes;
s
The following code should have no check for bytes == 0 but does on the mainline:
static int blocksize = 4096;
int bar (int);
void foo (void)
{
int toread;
int bytes;
static char eof_reached = 0;
toread = blocksize;
bytes = 1;
while (toread != 0)
{
bytes = bar (toread);
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
22:44 ---
Note after fixing PR 21559, we will be back to "is used" warning instead of
"may be used".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21548
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
22:47 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20714
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20769
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20793
1 - 100 of 138 matches
Mail list logo
