--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14
06:30 ---
(In reply to comment #11)
> Ralf, it looks like no working integer type is found when building the
> compiler.
The h8300 is special wrt. integer types:
>From a test script of mine:
...
checking for char
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-05-14 02:01 ---
(In reply to comment #6)
> Strict aliasing does not matter in this case as it is not enabled at -O1
> anyways.
It does! Although not with -O1. But I just wanted to point out (which I forgot
before
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-05-14 01:56 ---
(In reply to comment #5)
> This is an aliasing issue, -O1 -fno-ivopts -finline-functions works.
> DCE thinks the store to gfp->out_samplerate is dead.
>
> Note the code will seg fault right away an
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
01:46 ---
(In reply to comment #7)
> Oh and -fno-tree-saliasing does not fix it, this is just for Dan.
I mean "-fno-tree-salias".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21564
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
01:46 ---
Oh and -fno-tree-saliasing does not fix it, this is just for Dan.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21564
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-14 01:38
---
I've got a patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
01:35 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--
What|Removed |Added
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21557
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
01:29 ---
This is a common problem on all biarch systems when trying to compile in non
native mode for the
processor.
The reason why I thought it was a different person is because the summary made
it sound like it
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
01:25 ---
Oh, I thought this was a different person, woops.
--
What|Removed |Added
Status|
--- Additional Comments From Daniel dot Davies at xerox dot com 2005-05-14
01:23 ---
Goodness, this morning joseph from codesourcery said building multilibs was
the right thing to do. He said I should submit a proper bug report if the 32-
bit platform tried executing 64-bit code. Coul
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
01:20 ---
Strict aliasing does not matter in this case as it is not enabled at -O1
anyways.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
01:19 ---
This is an aliasing issue, -O1 -fno-ivopts -finline-functions works.
DCE thinks the store to gfp->out_samplerate is dead.
Note the code will seg fault right away anyways, you need the following change
to m
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
01:10 ---
some how the store is becoming dead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21564
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
01:09 ---
I have no idea what is causing the problem. I tried the following options and
it is still messed up:
" -O1 -finline-functions -fno-tree-dominator-opts -fno-tree-fre -fno-tree-ccp
-fno-tree-store-ccp
-fno
--- Additional Comments From janis187 at us dot ibm dot com 2005-05-14
00:54 ---
Subject: Re: [4.0 Regression] 3.4.4 RC1 fails libstdc++ install on
powerpc64-linux
I tried the 4.0 patch on powerpc64-linux with "make -j 8 bootstrap"
for c,c++,f95,objc,java, ran the testsuite, and insta
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-05-14 00:49 ---
(In reply to comment #0)
>
> But when compiling with only the following:
>
> --
> gcc -O1 -fno-strict-aliasing -finline-functions -o lame lame.c
>
--- Additional Comments From dje at gcc dot gnu dot org 2005-05-14 00:48
---
backported patch
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
00:47 ---
Note this now fails at -O3 -fno-inline (for 4.1.0).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21562
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz
2005-05-14 00:46 ---
Created an attachment (id=8887)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8887&action=view)
This is the testcode that triggers the bug (stripped from latest CVS LAME).
--
http://gcc.g
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-14
00:46 ---
Subject: Bug 21237
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-14 00:46:01
Modified files:
gcc: Change
Hi,
during compilation of LAME I found out that the following gcc
--
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../../gcc-CVS-20050512/gcc-CVS-20050512/configure
--host=i686-pc-linux-gnu --prefix=/usr/local/opt/gcc-4.1
--exec-prefix=/usr/local/opt/
--- Additional Comments From mckinlay at redhat dot com 2005-05-14 00:43
---
Fix checked in.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-14
00:43 ---
Subject: Bug 21557
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-05-14 00:43:10
Modified files:
libjava: Change
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-14
00:42 ---
Subject: Bug 21557
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-05-14 00:42:46
Modified files:
libjava: ChangeLog
libjava/java/lang:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
00:41 ---
(In reply to comment #1)
> Confirmed, it is not slight with checking enabled:
Which is really weird because it is not until expand time we catch it.
Oh and this ICEs on i686-pc-linux-gnu also.
--
Consider:
int
foo (int a)
{
if (a > 1)
if (a == 0)
return 1;
return 0;
}
The second "if" statement is not folded.
--
Summary: A trivial VRP opportunity missed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
00:24 ---
Confirmed, it is not slight with checking enabled:
pr21562.c: In function 'ping_recurse':
pr21562.c:15: error: Wrong amount of branch edges after unconditional jump 0
pr21562.c:15: error: verify_flow_info: I
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
00:19 ---
This is excepted behavior and is documented in the docs.
--
What|Removed |Added
Compile the following with -O2 -funroll-loops and you get bad codegen. An
uninitilaized value
is used as "pos" in computing the store address for mr[pos]=1 at the top of the
function. The
first dump where it's wrong seems to be "nrv". If you unroll by hand it comes
out correct.
extern int de
--- Additional Comments From roche at act-europe dot fr 2005-05-13 23:40
---
Subject: Re: GCC_EXEC_PREFIX mechanism is broken
pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
> 22:53 ---
> If I read the docs correc
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-13
23:27 ---
This no longer fails due to a change that went in as part of the fix
for PR 8618. In particular, we now emit the 'Inner' constructor as
package-private, not private.
This is kind of a slacker approach to im
When I build gcc 4.0.0 and g++ 4.0.0 using the newest configuration instructions
on a 32-bit processor, the g++ configuration script builds a 64 bit program,
fails to execute it and the build stops.
Configuring with --disable-multilib works around the problem.
Processor Pentium 4
OS: Solaris 2.10
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
23:06 ---
The only change which could have caused this would be RTH but I know RTH
bootstrapped and tested
the patch.
Are you sure that you are not using a broken binutils?
--
http://gcc.gnu.org/bugzilla/show_b
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
23:01 ---
Confirmed, here is a compile time testcase instead of a runtime:
template struct Z {
#pragma pack(1)
union Packed {
struct {
int dx:2;
int dy:2;
};
unsigned char byte;
};
#pragma pa
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
22:56 ---
Also the documenation has said since June 2001.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
22:53 ---
If I read the docs correctly it says you have to add -B. to the invocation.
See PR 19856 and 14435.
Reference from the docs:
In addition, the prefix is used in an unusual way in finding the directories to
Example below prints 4, should be 1.
If #pragma pack() is removed it prints 1, also it prints 1 if the printing line
is also wrapped in pragmas.
If instead template stuff is removed at all it prints 1 correctly.
--example--
#include
using namespace std;
template struct Z {
#pragma pack(1)
uni
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20793
--
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=20714
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-13
22:47 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
--- 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
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
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);
--- 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
--- 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: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 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
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 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:42 ---
I don't see what is wrong with the generated code, maybe a dead store.
--
What|Removed |Added
--- 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 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 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 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 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.
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 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
--- 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 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 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
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 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
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-05-
--- 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
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
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
--- 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
--- 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
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 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
--
What|Removed |Added
BugsThisDependsOn||20396
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20695
--
What|Removed |Added
OtherBugsDependingO||20695
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20396
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-05-13
18:30 ---
Fixed on mainline.
--
What|Removed |Added
Status|UNCONFIRMED |RE
--
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 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:
--- 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 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 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 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 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 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
--
What|Removed |Added
CC||roche at adacore dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21553
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/
--- 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
--- 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
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
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
--- 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
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
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
--- 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
--- 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 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 schwab at suse dot de 2005-05-13 15:00 ---
It is not _always_ uninitialized.
--
What|Removed |Added
Status|RESOLVED
--- 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 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:54 ---
The program logic guarantees that blocksize is never zero.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21548
--- 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
1 - 100 of 138 matches
Mail list logo
