--- Comment #2 from falk at debian dot org 2006-04-11 09:40 ---
It seems to me that t.p, which is of type char*, is accessed via an lvalue
of type long. So this is undefined behavior. Or am I missing something?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27114
--- Comment #10 from falk at debian dot org 2006-04-18 06:27 ---
Uhm, this has nothing to do at all with evaluation order. Evaluation
order of arguments is unspecified (not undefined, which wouldn't make a
lot of sense), but that is in fact irrelevant here, it could lead to,
say,
--- Comment #12 from falk at debian dot org 2006-04-18 12:37 ---
(In reply to comment #11)
> No, this testcase is unspecified, not undefined. There are intervening
> sequence points at the start and end of each call to function
OK.
> However, the evaluation of the
>
--- Comment #15 from falk at debian dot org 2006-04-19 14:20 ---
Roger's patch
http://gcc.gnu.org/ml/gcc/2006-04/msg8.html
fixes this. I don't know about the status of this patch, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
--- Comment #7 from falk at debian dot org 2006-04-23 19:05 ---
I think this is a valid request. While random language extensions aren't
useful,
compatibility with C99 is. Maybe somebody else can comment on this...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27235
--- Comment #2 from falk at debian dot org 2006-04-23 19:34 ---
Confirmed. Test case:
unsigned char rx_async(unsigned char p) {
return p & 512;
}
--
falk at debian dot org changed:
What|Removed |A
--- Comment #2 from falk at debian dot org 2006-04-25 12:19 ---
It's a valid C++ fragment. However, this code accesses "ptr", which is of type
void*, via an lvalue of type U16*. This is undefined behavior, so there is no
gcc bug here.
--
http://gcc.gnu.org/bugzilla/
--- Comment #4 from falk at debian dot org 2006-04-25 13:19 ---
The standard doesn't mention set::erase with "iterator" argument, only with
"const_iterator". Maybe it is legal for g++ to allow it anyway (even if I
cannot find anything in the standard allowi
--- Comment #5 from falk at debian dot org 2006-04-25 13:20 ---
(In reply to comment #4)
> The standard doesn't mention set::erase with "iterator" argument, only with
> "const_iterator".
erm. the other way round, of course.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17373
--- Comment #15 from falk at debian dot org 2006-05-01 20:55 ---
(In reply to comment #12)
> Subject: Re: goto crossing P.O.D. initialization
>
> "falk at debian dot org" <[EMAIL PROTECTED]> writes:
>
> | I think this is a valid request. While ra
: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC bui
ed at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27468
cc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27469
erity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27504
--- Comment #1 from falk at debian dot org 2006-05-16 12:40 ---
There is no guarantee that this happens, and it would suppress many useful
optimizations.
However, if you mark the fields as volatile, the ARM ABI guarantees that
the access will be in the specified width (and after PR
--- Comment #4 from falk at debian dot org 2006-05-18 15:47 ---
I did a regression test, I'll submit the patch tomorrow (I hope).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
--- Comment #8 from falk at debian dot org 2006-05-21 16:34 ---
(In reply to comment #7)
> This is interesting, I cannot reproduce this with a cross compiler to
> alphaev68-unknown-linux-gnu from powerpc-darwin.
Hrm :-(. Can anybody try a cross-compiler on i386 with va
--- Comment #1 from falk at debian dot org 2006-05-23 19:40 ---
This code accesses v, which is of type void*, via an lvalue of type int.
This is not allowed by C aliasing rules. Use -fno-strict-aliasing or a
union to express this operation.
--
falk at debian dot org changed
--- Comment #6 from falk at debian dot org 2006-05-26 12:30 ---
Fixed.
--
falk at debian dot org changed:
What|Removed |Added
Status|NEW
--- Comment #2 from falk at debian dot org 2006-06-04 12:51 ---
Here is a cleaned-up testcase:
int firstkey();
void DBM_error(int);
void domisc() {
int i = 0;
try {
try {
firstkey();
while (1) {
i++;
firstkey
--- Comment #8 from falk at debian dot org 2006-06-06 21:04 ---
(In reply to comment #7)
> PR 23971 is closed as fixed, I don't know if alpha is having this problem
> anymore or not.
It takes 3.39s now, which while much faster than it used to be is still
ridiculously slow
--- Comment #1 from falk at debian dot org 2006-06-07 08:12 ---
Confirmed with 4.2.0 20060606. Cleaned up test case:
struct fann_neuron {
double value;
} __attribute__ ((packed));
void fann_run (struct fann_neuron **last_neuron) {
while (1)
(*last_neuron)->value
--- Comment #39 from falk at debian dot org 2006-06-08 15:02 ---
I'm not actually working on this at the moment
--
falk at debian dot org changed:
What|Removed |
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28015
--- Comment #1 from falk at debian dot org 2006-06-15 10:16 ---
If the value of the integral part cannot be represented by the integer type,
the behavior is undefined. So this is not a bug.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #1 from falk at debian dot org 2006-06-28 17:57 ---
Shifting by an amount larger than the size of a type is undefined behavior,
so anything might happen. Gcc even warns about this.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #3 from falk at debian dot org 2006-07-06 20:14 ---
(In reply to comment #2)
> Even if I add directly to extc++.h (a complete hack), the
> compilation errors about iconv_t missing are gone, but the ICE remains,
> even at -O0.
Can you give the .ii for that?
-
--- Comment #10 from falk at debian dot org 2006-07-08 07:24 ---
I see the same on alphaev68-linux-gnu.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #1 from falk at debian dot org 2006-07-13 20:58 ---
The conversion from int* to aa* is only defined if the pointer is correctly
aligned. Even if it was correctly aligned, dereferencing this pointer is
undefined behavior (see -Wstrict-aliasing documentation). So this is not
--- Comment #3 from falk at debian dot org 2006-07-14 08:08 ---
This simplified test case ICEs already at -O:
static const long unsigned sizes[] = { 4, 8 };
static long unsigned maxSize(const long unsigned *v) {
unsigned long max = 0;
unsigned long i = 0;
for
--- Comment #2 from falk at debian dot org 2006-07-14 12:26 ---
This is a duplicate of PR 26881.
*** This bug has been marked as a duplicate of 26881 ***
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #13 from falk at debian dot org 2006-07-14 12:26 ---
*** Bug 28379 has been marked as a duplicate of this bug. ***
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #1 from falk at debian dot org 2009-01-24 17:48 ---
const char *logout_cmd = logout_cmd;
actually initializes the variable with its own (uninitialized) value.
You can get a warning about this with "-Winit-self".
--
falk at debian dot org changed:
--- Comment #3 from falk at debian dot org 2009-01-28 14:25 ---
We need the preprocessed source of a *complete* (including main) program to be
able to reproduce this.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #5 from falk at debian dot org 2009-01-28 14:44 ---
(In reply to comment #4)
> What I can try is finding the revision which causes the fault.
While that would certainly be helpful, it's unlikely that anybody would be
willing to debug this without a usable
--- Comment #2 from falk at debian dot org 2009-07-13 14:19 ---
It bootstraps now, except that it fails for objc. I'll file a bug report for
that later.
--
falk at debian dot org changed:
What|Removed |
--- Comment #1 from falk at debian dot org 2005-11-20 13:33 ---
There is no "correct" output when you use a variable uninitialized. It's
undefined behavior. Printing any number, or crashing, would be completely
valid behaviors as far as gcc is concerned.
--
falk at
--- Comment #4 from falk at debian dot org 2005-11-20 14:35 ---
I already explained this. Using an uninitialized variable invokes undefined
behavior. This means that producing random junk, executing random if
statements,
executing random if statements 17 times, formatting your hard
--- Comment #3 from falk at debian dot org 2005-11-24 17:01 ---
Well, there's one actual issue here, namely that there is no warning about:
int f() {
int x = 40;
return 1 << x;
}
even though we could of course detect this, albeit probably only in the
middle-end.
--- Comment #5 from falk at debian dot org 2005-12-05 09:02 ---
(In reply to comment #4)
> It is NOT a problem of GCC
OK, let's close it, then.
--
falk at debian dot org changed:
What|Removed
--- Comment #3 from falk at debian dot org 2005-12-15 08:41 ---
I cannot reproduce this on alphaev68-linux with 4.0.3 20051201 (prerelease),
4.1.0 20051124 (prerelease), or 4.2.0 20051124 (experimental). Could you
perhaps try a newer version (4.0.2) or even better a recent snapshot
--- Comment #5 from falk at debian dot org 2005-12-16 21:34 ---
(In reply to comment #4)
> It does NOT occur under
> gcc version 4.0.3 20051208 (prerelease)
Okay, so let's close it, then.
--
falk at debian dot org changed:
What|Removed
--- Comment #2 from falk at debian dot org 2006-01-04 22:39 ---
Actually, using a table is faster when the cache is hot (about 15%).
The problem is that libgcc doesn't unroll the loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25674
--- Comment #3 from falk at debian dot org 2006-01-05 10:36 ---
(In reply to comment #2)
> please resolve this as duplicate for bug 5520
OK.
*** This bug has been marked as a duplicate of 5520 ***
--
falk at debian dot org changed:
What|Remo
--- Comment #6 from falk at debian dot org 2006-01-05 10:36 ---
*** Bug 19773 has been marked as a duplicate of this bug. ***
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #2 from falk at debian dot org 2006-07-20 14:53 ---
However, gcc chould actually warn about while loops with an empty body where
the exit condition has no side effects. This might be slightly difficult,
though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28446
--- Comment #2 from falk at debian dot org 2006-08-10 21:11 ---
Confirmed. This is a smaller test case:
int vformat(char *buffer) {
return buffer[32767];
}
This needs -mcpu=ev45. It is triggered by the synthetization
of the 8-bit load by 64-bit loads. ldb v0, x(a0) is done as
lda
--- Comment #1 from falk at debian dot org 2006-08-22 10:16 ---
Correct, the warning should say "ISO C forbids an empty translation unit".
--
falk at debian dot org changed:
What|Removed
--- Comment #7 from falk at debian dot org 2006-08-25 12:07 ---
Can you still reproduce this? As Andrew points out, it is probably fixed...
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #11 from falk at debian dot org 2006-09-19 17:38 ---
No feedback for a long time, let's just close it.
--
falk at debian dot org changed:
What|Removed |
--- Comment #1 from falk at debian dot org 2006-09-24 19:52 ---
For this test case:
void f(double *pds, double *pdd, unsigned long len) {
while (len >= 8*sizeof(double)) {
register double r1,r2,r3,r4;
r1 = *pds++;
r2 = *pds++;
r3 = *pds++;
r4 = *pds++;
*
--- Comment #9 from falk at debian dot org 2006-10-01 21:50 ---
FWIW, the same problem breaks bootstrap on Alpha Linux:
http://buildd.debian.org/fetch.php?&pkg=gcc-snapshot&ver=20060922-1&arch=alpha&stamp=1158945554&file=log&as=raw
--
http://gcc.gnu.org/
--- Comment #2 from falk at debian dot org 2006-10-13 12:43 ---
>From the standard:
[...] n can have the value zero on a call to that function. Unless
explicitly stated otherwise in the description of a particular
function in this subclause, pointer arguments on such a call sh
--- Comment #5 from falk at debian dot org 2006-10-13 12:52 ---
I also think the diagnostics should be improved.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #3 from falk at debian dot org 2007-07-22 23:01 ---
Can you give an example how n->next->next->prev and n->next might be at the
same address? I don't see any legal way to achieve that.
And FWIW, DEC C also optimizes like gcc does.
--
falk at debia
--- Comment #5 from falk at debian dot org 2007-07-22 23:19 ---
Well, certainly not legal in C, since there you may only access the element of
a union last written to. However, in GNU C, other accesses are allowed.
--
falk at debian dot org changed:
What|Removed
--- Comment #7 from falk at debian dot org 2007-07-23 14:17 ---
(In reply to comment #6)
> This program demonstrates the problem, it creates different output depending
> on
> if compiled with or without optimisation.
This does not demonstrate the problem, since your code has
--- Comment #9 from falk at debian dot org 2007-07-25 08:24 ---
(In reply to comment #8)
> You may only access union members through the union, not through other
> pointers.
Where is this documented? I thought it should be in extend.texi, but I couldn't
find it...
--- Comment #9 from falk at debian dot org 2007-07-26 22:49 ---
(In reply to comment #8)
> Bug 32747 fixed, so I successfully bootstrapped r126943 (all languages minus
> java) with patch from comment #6 on alphaev56-unknown-linux-gnu.
>
So, are you going to post the pat
--- Comment #5 from falk at debian dot org 2007-08-01 20:15 ---
Actually, two lines suffice:
template static inline void f() { }
template<> inline void f<5>() { }
This also breaks inkscape.
--
falk at debian dot org changed:
What
ot org
ReportedBy: falk at debian dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33142
--- Comment #5 from falk at debian dot org 2007-09-24 20:18 ---
As noted by Edvin Török, the bug is not fixed for the original test case
(although it is fixed for the small test case). A small test case that still
fails is
int f(void);
void acceptloop_th(int *t) {
int options = 0
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host triplet: alphaev68-unkno
--- Comment #2 from falk at debian dot org 2007-10-18 06:27 ---
Whoops.
void f(unsigned char *s, unsigned char *d, int n) {
int i;
for (i = 0; i < n; i += 4) {
d[i + 0] += s[i + 0];
d[i + 1] += s[i + 1];
d[i + 2] += s[i + 2];
d[i + 3] += s[i
--- Comment #4 from falk at debian dot org 2007-10-18 19:26 ---
Created an attachment (id=14370)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14370&action=view)
Vectorization dump file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
--- Additional Comments From falk at debian dot org 2005-02-18 12:38
---
This code is invalid; you're accessing an object of type uint64_t via a pointer
to uint32_t, which is not allowed. Use -fno-strict-aliasing, or use a union.
--
What|Re
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: alphaev68-unknown-linux-gnu
GCC host triplet: alphaev68-unknown-linux-gnu
GCC target triplet: alphaev68-
--- Additional Comments From falk at debian dot org 2005-02-20 11:13
---
Created an attachment (id=8238)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8238&action=view)
test case (compile with no options)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103
--- Additional Comments From falk at debian dot org 2005-02-21 11:19
---
(In reply to comment #2)
> Any chance to do something about it on older versions? (3.2.x 3.3.x
> 3.4.x)
No. We fix only regressions or very serious bugs in those versions.
--
http://gcc.gnu.org/bu
--- Additional Comments From falk at debian dot org 2005-02-22 13:40
---
Confirmed, this is an ICE on invalid code. This is a test case for 4.0 (but
for some reason it doesn't work for 3.4):
struct ED_Ligne { int x; };
void dealloue_ligne();
void dealloue_buff(struct ED_
--- Additional Comments From falk at debian dot org 2005-02-23 19:52
---
"int i = i" does not do what you think it does. It initializes i with the
yet-uninitialized new i. So this is invalid code.
--
What|Removed
--- Additional Comments From falk at debian dot org 2005-02-23 22:18
---
(In reply to comment #2)
> I
> wanted to submit the *.i file just in case you wanted to look at it but the
> file
> is over 1MB and it says it is too large.
Compress it with bzip2 and use &
--- Additional Comments From falk at debian dot org 2005-02-24 07:30
---
(In reply to comment #2)
> I tried the -fno-strict-aliasing option, but this generates the same code.
Okay, let's reopen this then for now.
--
What|Removed
--- Additional Comments From falk at debian dot org 2005-02-24 10:21
---
You are accessing an object of type "class data" via a pointer to uint64, which
is not allowed in C++. So this is invalid.
--
What|Removed
--- Additional Comments From falk at debian dot org 2005-02-24 10:57
---
(In reply to comment #2)
> The cast is, perhaps, illegal.
No, the cast is fine. The access is bad.
> But after the cast there is an assignment from
> uint32 to uin64. And that assignment does not wor
--- Additional Comments From falk at debian dot org 2005-02-24 10:58
---
(In reply to comment #3)
> The reinterpret_cast solves the problem with this old code.
>
> inline data::data ( uint32 num ) { *reinterpret_cast(this) = num; }
That is pure luck; the code is stil
--- Additional Comments From falk at debian dot org 2005-02-24 11:00
---
Invalid for the same reason as PR 20184...
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From falk at debian dot org 2005-02-24 12:59
---
(In reply to comment #2)
> (In reply to comment #1)
> > Invalid for the same reason as PR 20184...
> >
>
> I get the same failure if I use (little endian system)
> inline data::
--- Additional Comments From falk at debian dot org 2005-02-24 14:21
---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > (In reply to comment #1)
> >
> > You are accessing an object of type "class data" thr
&&
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot o
--- Additional Comments From falk at debian dot org 2005-02-27 11:16
---
The C standard does in fact not allow this conversion. However,
I agree that it might be nice to have an option for semantics as in the
C++ standard (4.4). They allow this, and it is safe.
--
http://gcc.gnu.org
--- Additional Comments From falk at debian dot org 2005-02-27 11:23
---
Here's a paper about this if anybody wants to do this systematically:
Saman Amarasinghe, Walter Lee, Ben Greenwald.
Strength Reduction of Integer Division and Modulo Operations
LCPC 2001
http://www.lcs.mi
--- Additional Comments From falk at debian dot org 2005-02-27 13:20
---
(In reply to comment #5)
> Am I wrong? Where does it state in the C standard that you cannot perform a
> multi-level qualifier promotion?
Nowhere. It follows from the fact that it is not allowed explici
--- Additional Comments From falk at debian dot org 2005-03-04 12:51
---
(In reply to comment #0)
> Probably, this is not a bug but a feature
Indeed, it is.
> but what can I do
> to my program, which needs a lot of packed structures and runs fine
> with gcc3.3?
Noth
--- Additional Comments From falk at debian dot org 2005-03-08 10:11
---
I can reproduce this with 3.4.4 20041218 (prerelease) (Debian 3.4.3-6)
(i486-linux), but not with 3.4.4 20050203 (prerelease) (Debian 3.4.3-9)
(alpha-linux). Probably it's already fixed.
Test case:
--- Additional Comments From falk at debian dot org 2005-03-08 14:25
---
Confirmed. This is triggered by a bogus argument for an output constraint.
Not a regression.
void f() {
__asm__ ("" : "=r" ("r5"), "+r" ("r5"));
}
--
nd what I can derive from that about the
mistake I made. But maybe that's just me.
--
Summary: Lame error message for undefined type
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: nor
--- Additional Comments From falk at debian dot org 2005-03-09 09:14
---
(In reply to comment #4)
> Where can I find some documentation on using this extended asm format? I
> have read all the GNU docs on it and can not understand how to use it.
Well, those docs are all we ha
--- Additional Comments From falk at debian dot org 2005-03-09 12:30
---
(In reply to comment #6)
> I guess I'm not properly interpreting the documentation on how to use
> registers in the asm, is that correct?
Yes, that's correct :-) I suggest you ask at [EMAIL PROTEC
--- Additional Comments From falk at debian dot org 2005-03-11 10:36
---
(In reply to comment #0)
> Opinion:
> The default set of warnings for gcc is not sane, and
> eventually causes lower quality code.
The default does not follow "sanity", but it follows
*** [bootstrap] Error 2
--
Summary: Bootstrap failure on alphaev56
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot o
--- Additional Comments From falk at debian dot org 2005-03-11 13:28
---
(In reply to comment #0)
> # test.c
> static const unsigned major = 0;
> static const unsigned minor = 9;
> static const unsigned build = 1;
> const unsigned version = (major << 24) |
--- Additional Comments From falk at debian dot org 2005-03-11 17:25
---
(In reply to comment #3)
> Invalid or not, the request for changing the error message in the other case
> still stands for reasons mentioned: It's impossible currently to distinguish
> between the
--- Additional Comments From falk at debian dot org 2005-03-11 18:03
---
(In reply to comment #5)
> warning: passing arg 1 of `mymalloc':
> 'void **' differs in levels of indirection from 'char *'
>
> My suggestion therefore would be to
--- Additional Comments From falk at debian dot org 2005-03-12 20:43
---
I think I know why this happens: there's a bug in alpha_fold_builtin_cmpbge.
Will test a patch.
--
What|Removed |
--- Additional Comments From falk at debian dot org 2005-03-13 13:42
---
(In reply to comment #0)
> I am sorry I can't provide a verified to fail snippet,
> since I don't have access to that version of GCC. The
> following is an untested attempt to reproduce the
&g
--- Additional Comments From falk at debian dot org 2005-03-14 15:03
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From falk at debian dot org 2005-03-29 10:45
---
I can reproduce this with GNU C version 3.4.4 20050314 (prerelease)
(Debian 3.4.3-12) (alpha-linux).
This seems to be cause by unit-at-a-time inlining and implicit prototypes.
4.1 ICEs with
test.c:4: internal
--- Additional Comments From falk at debian dot org 2005-03-29 13:03
---
I can reproduce this with gcc 4.0.0 20050329 on alphaev68-unknown-linux-gnu.
Test case:
struct BS {
int i;
char c[46];
};
void foo(struct BS* p)
{
int i;
for (i = 0; p->c[i]
--- Additional Comments From falk at debian dot org 2005-03-29 13:12
---
This looks similar to the (fixed) PR 17949. Zdenek, do you have any ideas?
--
What|Removed |Added
1 - 100 of 320 matches
Mail list logo
