https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83993
--- Comment #1 from Falk Hueffner ---
/tmp% cat test.cc
extern const int table[];
const int* const ptable = [0];
int f() { return ptable[0]; }
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: falk at debian dot org
Target Milestone: ---
/tmp% g++ --version
g++ (GCC) 8.0.1 20180119 (experimental)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions
--- Comment #2 from falk at debian dot org 2010-06-09 19:11 ---
Confirmed, seems to be in if-conv. Here's a smaller test case:
int ffesum (void) {
int ch[4], ii, jj, kk;
char asc[32];
for (ii = 0; ii 4; ii++)
{
for (jj = 0; jj 4; jj++)
ch[jj] = ii
--- Comment #2 from falk at debian dot org 2010-05-05 22:46 ---
Confirmed, here is a smaller testcase:
extern inline
void add_1(int *dst, const int *src, int n) {
if (n)
dst[n] = src[n];
}
typedef void (*aors_1_t)(int *, const int *, int);
aors_1_t fudge(aors_1_t f) {
return
--- Comment #3 from falk at debian dot org 2010-05-01 23:11 ---
Confirmed. Here is a test case that gives:
mini.cc: In member function uploadMessage:
mini.cc:6:49: internal compiler error: tree check: expected class type, have
declaration (function_decl) in gen_type_die_with_usage
--- Comment #2 from falk at debian dot org 2010-04-22 07:35 ---
Confirmed on x86-64, already in 4.3, but not in 4.1. Here is a testcase that
gives an SSA verification error on 4.6 instead of segfaulting:
typedef int __attribute__ ((const)) (*x264_pixel_cmp_t)(void);
typedef struct
--- Comment #8 from falk at debian dot org 2010-04-19 20:25 ---
Confirmed with current 4.6 on x86-64, here is a testcase:
int owner();
int clear();
static void fixup() {
clear();
}
inline __attribute__ ((always_inline))
void slowtrylock(void) {
if (owner())
fixup
--- Comment #2 from falk at debian dot org 2010-03-26 12:28 ---
Unary plus is allowed in standard C. Use -Wtraditional to get a warning.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #8 from falk at debian dot org 2010-03-26 15:30 ---
This seems to be a problem with the struct hack in QVector. Here is a test
case:
extern C {
void *memset(void *s, int c, __SIZE_TYPE__ n);
void *malloc(__SIZE_TYPE__ size);
int printf(const char *format
--- Comment #3 from falk at debian dot org 2010-03-14 23:35 ---
Confirmed, here is a testcase:
int fragile_block(void) {
typedef __attribute__ ((aligned (16))) struct {
int i;
} XmmUint16;
return 0;
}
--
falk at debian dot org changed:
What|Removed
--- Comment #5 from falk at debian dot org 2009-09-29 21:02 ---
Of course the optimization would be wrong if the second clause had side
effects, but it doesn't and this will frequently be the case. So this is
definitely a valid and in my opinion worthwhile optimization.
--
http
--- Comment #1 from falk at debian dot org 2009-04-20 15:28 ---
Removing the default constructor is a bad idea, since it would break about any
available library including the standard lib in subtle ways, and would make g++
pretty much unusable.
But apparently this isn't actually what
--- Comment #2 from falk at debian dot org 2009-04-14 14:47 ---
The problem comes from some convoluted code that was apparently substituted for
strlen to special-case constant arguments. It boils down to:
int f(void) {
if (0)
return ((const char *) )[2];
return 0;
}
(without
--- Comment #4 from falk at debian dot org 2009-04-07 21:47 ---
Here's a test case:
unsigned long f1();
int f2();
int store_aff_word(int x) {
return (int) (x ? f1() : f2());
}
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #19 from falk at debian dot org 2009-03-18 09:06 ---
(In reply to comment #18)
I can't imagine an implementation of memcpy that would break when the two
addresses are the same, it just doesn't work if one is offset but
overlapping.
So the valgrind warning
--- Comment #6 from falk at debian dot org 2009-03-17 12:10 ---
(In reply to comment #1)
calling memcpy with exactly overlapping operands is safe (obviously).
It's not safe at all. A memcpy implementation might use a prefetch with write
intent instruction that allocates a cache line
--- Comment #19 from falk at debian dot org 2009-03-16 10:24 ---
(In reply to comment #18)
Well, I've got bad news for you anyway:
it seems that the problem affects gcc-4.3.2 too:
it seems it's reproducible in another app,
however one potentially much harder to debug.
Please read
--- Comment #5 from falk at debian dot org 2009-03-09 10:59 ---
Here's a test case:
void *p;
extern inline void *f1(int n) {
asm volatile( : =m(*(struct { char x[n]; }*) p));
}
int x;
extern inline void f2() {
x ? f1(1) : f1(2);
}
inline void f3() { f2(); }
void f4() { f3
--- Comment #1 from falk at debian dot org 2009-03-02 11:43 ---
Why not just use -fcall-saved-reg for the relevant registers?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39341
: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build triplet: alphaev68-linux-gnu
GCC host triplet: alphaev68-linux-gnu
GCC target triplet: alphaev68-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39108
--- Comment #11 from falk at debian dot org 2009-02-03 12:50 ---
(In reply to comment #10)
By changing the test to:
unsigned int p[64];
In this case 8-byte alignment is guaranteed, so no peeling is needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18557
--- Comment #2 from falk at debian dot org 2009-02-02 19:02 ---
No problem with the trunk, but it's still there in the 4.3 branch.
Here's a test case. Requires -funroll-loops -Os, no problem with any other -O,
or without -funroll-loops, curiously.
int f(int x, int y) {
int bytes
--- Comment #3 from falk at debian dot org 2009-02-01 10:50 ---
The main problem is that just replacing the code by the below loop won't
necessarily give a speedup. strlen is usually implemented in highly efficient
and platform-specific assembly that treats several bytes at a time. I
--- 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 testcase
--- 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:
What
--- Comment #3 from falk at debian dot org 2008-05-14 11:08 ---
(In reply to comment #2)
Regarding gnat; Can we use this ticket for tracking the problem?
No, please file a new bug. Or is this the same as PR 36025?
--
falk at debian dot org changed:
What|Removed
--- Comment #1 from falk at debian dot org 2008-05-02 13:55 ---
I can reproduce this with 4.1, but not with 4.2.3 or 4.3.1 20080401. So it
seems to be fixed.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #3 from falk at debian dot org 2008-03-24 16:23 ---
I can't reproduce this on Alpha Linux with Debian 4.2.3-2. On that system, long
double is 16 bytes. What's the length on your system? Also, can you try 4.3?
--
falk at debian dot org changed:
What
--- Comment #3 from falk at debian dot org 2007-12-23 21:46 ---
(In reply to comment #2)
Falk, do you think you could check if this is still an issue?
It's very unlikely to be fixed. The fix mentioned seems to be right, but
without a big-endian Alpha system to test the patch on I
--- Comment #8 from falk at debian dot org 2007-10-22 13:47 ---
(In reply to comment #7)
Could you please check if the patch in Comment #6 fixes the ICE?
Yes, this fixes it. Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
--- 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 + 3
--- 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=14370action=view)
Vectorization dump file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
-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-unknown-linux-gnu
GCC target
--- 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
code with abs in comparison
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk
--- Comment #5 from falk at debian dot org 2007-08-01 20:15 ---
Actually, two lines suffice:
templateunsigned x static inline void f() { }
template inline void f5() { }
This also breaks inkscape.
--
falk at debian dot org changed:
What|Removed
--- 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 patch to gcc-patches
--- 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...
--
http
--- 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 undefined
--- 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 debian dot org changed
--- 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 #2 from falk at debian dot org 2007-07-05 13:01 ---
I tried this patch from Andrew Pinski:
Index: gcc/config/alpha/alpha.c
===
--- gcc/config/alpha/alpha.c(revision 126053)
+++ gcc/config/alpha/alpha.c
behavior in PRE
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk
--- Comment #1 from falk at debian dot org 2007-06-28 20:15 ---
Created an attachment (id=13801)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13801action=view)
Original test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
--- Comment #7 from falk at debian dot org 2007-06-27 15:37 ---
This makes bootstrap fail on alphaev68-linux:
/src/gcc-2007.06.27/build/./gcc/xgcc -B/src/gcc-2007.06.27/build/./gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/
-B/usr/local/alphaev68-unknown-linux-gnu/lib/ -isystem
on Alpha due to pointer-plus changes
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build
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=31911
--- Comment #1 from falk at debian dot org 2007-05-13 13:49 ---
Created an attachment (id=13546)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13546action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31911
--- Comment #4 from falk at debian dot org 2007-04-28 14:21 ---
Not a problem in 4.1 anymore, so let's close it.
--
falk at debian dot org changed:
What|Removed |Added
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
GCC build triplet
--- Comment #2 from falk at debian dot org 2006-11-02 13:36 ---
Please attach the .i file as obtained by adding -save-temps. Also, please try a
newer gcc version, the 3.3 branch is dead.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #3 from falk at debian dot org 2006-11-02 13:40 ---
Confirmed with a native 4.1.2 20061020.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #5 from falk at debian dot org 2006-10-29 09:57 ---
Zdenek,
do you think this patch (or another fix) can be backported to 4.1?
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01259.html
--
falk at debian dot org changed:
What|Removed
Version: 4.1.2
Status: UNCONFIRMED
Keywords: wrong-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: alpha
--- Comment #2 from falk at debian dot org 2006-10-28 23:13 ---
(In reply to comment #1)
What happens if you try -O2 -fno-loop-optimize?
No crash then.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29631
--- Comment #3 from falk at debian dot org 2006-10-22 12:50 ---
This bug is still there in 4.1, but not in mainline.
Janis, can you perhaps do a regression hunt to see what fixed this and whether
it is feasible to backport?
--
falk at debian dot org changed:
What
--- 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 shall
--- 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 #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-snapshotver=20060922-1arch=alphastamp=1158945554file=logas=raw
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27936
--- 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++;
*pdd
--- 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 |Added
--- 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 #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 |Added
--- 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 #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 #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
--- 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 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
--- 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 #3 from falk at debian dot org 2006-07-06 20:14 ---
(In reply to comment #2)
Even if I add iconv.h 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?
--
http
--- 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
--
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 #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 |Added
--- 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 = 1
--- 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 (with 1
--- 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 #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 #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 #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 valgrind
--- 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 #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
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
: 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 build triplet: alphaev68-unknown-linux-gnu
GCC host triplet
: unassigned 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
not eliminated
Product: 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
--- 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 random language extensions aren't
| useful
--- 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/show_bug.cgi?id
--- 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 allowing it at the moment), but other
--- 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 #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 |Added
--- 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 #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, 3 1 2
--- 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
arguments to printf
--- 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 #2 from falk at debian dot org 2006-04-08 08:06 ---
I cannot reproduce this anymore with 4.2.0 20060407, so closing.
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #4 from falk at debian dot org 2006-04-08 08:25 ---
I don't see this problem anymore in 4.2.0 20060407, so closing.
--
falk at debian dot org changed:
What|Removed |Added
1 - 100 of 317 matches
Mail list logo
