--- Additional Comments From falk at debian dot org 2005-03-29 20:23
---
(In reply to comment #6)
> This most likely can be reproduced on ia64 too and other targets where
alignment is needed for some
> loads.
I cannot reproduce it with -mcpu=ev56, though, so maybe it needs a p
--- Additional Comments From falk at debian dot org 2005-03-29 21:38
---
(In reply to comment #9)
> This patch should fix the problem
Yes, it does. (I haven't tried bootstrapping, though.)
Thanks for fixing this so quickly!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20625
--- Additional Comments From falk at debian dot org 2005-03-30 10:06
---
I don't understand what you mean. Please provide a *complete* test case,
with the command line you use and the output you get, and an explanation
of why you want a warning.
--
What|Re
--- Additional Comments From falk at debian dot org 2005-03-30 12:23
---
(In reply to comment #2)
> I mean that since in case where you are doing "void *p=(void *)&i" then
> according to strict-aliasing rules we get " warning: dereferencing type-punned
&g
--- Additional Comments From falk at debian dot org 2005-04-12 08:07
---
(In reply to comment #3)
> This code from stl_bvector.h is the problem: [...]
Hmm, right. I don't fully understand why it is done in this complicated
manner, does vector::operator[] need to do anything m
--- Additional Comments From falk at debian dot org 2005-04-18 08:10
---
(In reply to comment #6)
> Hi. It can well be a libstdc++ problem, and indeed I can imagine ways to avoid
> signed integers in the code. However, I'm not sure that someone will actually
> do the w
--- 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:
--- 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 ti
--- 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) {
--- 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
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: 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 #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
--- 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()
--- 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 har
--- 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
--- 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 t
--- 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 |
--- 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;
}
--- 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
--- 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.
--
--- 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 |
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=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=13546&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31911
--- 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
Bootstrap failure 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: fa
0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: 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=32540
--- 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=13801&action=view)
Original test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32540
--- 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
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
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 = &table[0];
int f() { return ptable[0]; }
--- Additional Comments From falk at debian dot org 2005-08-30 19:14
---
(In reply to comment #3)
> Actually, this looks like a more generic problem, not limited to Java.
In C, signed overflow is undefined, so any result or behavior would be
acceptable.
--
http://gcc.gnu.
--- Additional Comments From falk at debian dot org 2005-09-01 06:19
---
Works for me on alphaev68-unknown-linux-gnu
tiw with 4.1.0 20050819.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23666
--- Additional Comments From falk at debian dot org 2005-09-02 13:02
---
Works for me with any gcc version:
[EMAIL PROTECTED]:/tmp% gcc-3.4 -c test.c
test.c:1: warning: useless keyword or type name in empty declaration
test.c:2: warning: useless keyword or type name in empty
everity: normal
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23723
--- Additional Comments From falk at debian dot org 2005-09-04 15:08
---
Backing out
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/toplev.c.diff?cvsroot=gcc&r1=1.944.2.4&r2=1.944.2.5
from Mark's patch to PR 21828 makes the problem go away.
--
Wha
--- Additional Comments From falk at debian dot org 2005-09-06 08:04
---
(In reply to comment #0)
> macro.cc:24:1: error: pasting "->" and "setint" does not give a valid
> preprocessing token
That's a correct error message.
You don
--- Additional Comments From falk at debian dot org 2005-09-08 07:36
---
Reassign to Mark Mitchell, since his patch caused this and he requested to be
assigned in this case.
--
What|Removed |Added
--- Additional Comments From falk at debian dot org 2005-09-09 10:07
---
(In reply to comment #0)
> There are many reasons. (One and the best is to switch a double based on
> intervals) Therefore I would like a VERY FAST FUNCTION to return the sign of a
> double (and float
--- Additional Comments From falk at debian dot org 2005-09-12 19:19
---
(In reply to comment #14)
> Why not reopen this to add a -Wundefined-behavior, so that at least bugs like
> that could be caught up front when using -Werror?
There is already an unconditional warning, s
--- Additional Comments From falk at debian dot org 2005-09-12 19:22
---
In case anybody wants to work on this, I have an old unfinished patch lying
around that adds builtins and RTL codes for byteswap operation. This allows
to use platform specific tricks that almost any platform has
--- Additional Comments From falk at debian dot org 2005-09-13 06:19
---
(In reply to comment #16)
> Oh? I had -Werror on, and was not getting any warning at all from my code
> that
> was generating 'int $0x5' with gcc 3.4.1. It's perhaps a slightly differen
--- Additional Comments From falk at debian dot org 2005-09-19 12:28
---
(In reply to comment #0)
> The -Wparentheses switch (as well as -Wall) doesn't catch logical assignments
used as truth values. For example:
>
> int i = 0;
>
> if (i |= 1) {};
> if (i
--- Additional Comments From falk at debian dot org 2005-09-19 13:14
---
(In reply to comment #2)
> Well, all these examples are assignments. I don't agree that '=' is a somewhat
> unique or special assignment.
But of course it is. It is the only case where
--- Additional Comments From falk at debian dot org 2005-09-19 21:18
---
Confirmed. Test case:
void rgb_ycc_start(long *rgb_ycc_tab) {
long i;
for (i = 0; i <= 255; i++)
rgb_ycc_tab[i] = 19595 * i;
}
These 4 lines take 27 seconds to compile, nearly all of which
--- Additional Comments From falk at debian dot org 2005-09-20 12:45
---
Slightly simplified test case:
unsigned long f(unsigned long x) { return x * 5445825408751490200UL; }
(compile time 33.49s)
So it's just synth_mult running amok, and this has nothing to do with i
--- Additional Comments From falk at debian dot org 2005-09-20 13:01
---
This is also reproducible with 4.0.2 20050913, but not 3.4.5 20050821 (well, it
takes 0.5 seconds there, which also seems quite excessive).
--
What|Removed |Added
Component: tree-optimization
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: alpha-linux-gnu
GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu
http
--- Additional Comments From falk at debian dot org 2005-09-24 09:39
---
(In reply to comment #21)
> There have been lots of messages exchanged on this topic. It was just
> pointed to me that the C++ standard -- unlike the C99 standard -- has the
> following wording 5.7/7
--- Comment #2 from falk at debian dot org 2005-10-03 20:48 ---
(In reply to comment #0)
> The offset of "p5" member is 25 bytes, but compiler thinks that "p5" is
> aligned
> in "foo" function
You are casting a pointer to a Foo* that doesn
--- Comment #4 from falk at debian dot org 2005-10-04 07:32 ---
(In reply to comment #3)
> Correct me if I wrong, but loading long from passed pointer to char minus 4
> is not correct too.
You are right, I misread the example, the pointer that is cast to Foo* is
actually cor
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords
--- Comment #3 from falk at debian dot org 2005-10-09 12:42 ---
(In reply to comment #2)
> But the modified register is a register of the input list, so gcc should
> know that it will be used.
It knows it is being read. It doesn't know that it is also clobbered.
--- Comment #1 from falk at debian dot org 2005-10-12 10:06 ---
Confirmed. Test case:
int printf(const char *format, ...);
int f() {
printf("%d", 141592653589793238462643383279502884197169399375105820974944);
}
--
falk at debian dot org changed:
What
--- Comment #6 from falk at debian dot org 2005-10-15 15:04 ---
OK, let's have a look at this somewhat minimal example:
struct S {
long l;
unsigned char c;
};
unsigned long f(unsigned char *p10) {
struct S *p = (struct S *) (p10 + 10);
return p->c;
}
What we
--- Comment #3 from falk at debian dot org 2005-10-16 08:43 ---
Created an attachment (id=10001)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10001&action=view)
Reduced test case
This is an auto-reduced test case, can probably be reduced more.
--
http://gcc.gnu.org/b
--- Comment #2 from falk at debian dot org 2005-10-16 09:07 ---
(In reply to comment #1)
> Please read http://gcc.gnu.org/bugs.html. Also have a look at
> bug 323 and its duplicates.
Well, brushing off equality of 5*10^4931 and 0 as rounding error is maybe
stretching it a bit ;-
--- Comment #8 from falk at debian dot org 2005-10-22 22:42 ---
(In reply to comment #7)
> Can someone try sparc-linux, I would not doubt this could be reproduced there
> too.
Actually, it can't, as I tried to explain in comment #6, it is probably a
bug in config/alpha/pr
--- Comment #1 from falk at debian dot org 2005-10-25 12:40 ---
(In reply to comment #0)
>*memptr++ = (unsigned char)donothing(*memptr, 0);
This expression modifies memptr after accessing it for something other
than determining the new value without an intervening sequence po
--- Comment #10 from falk at debian dot org 2005-11-03 20:20 ---
Created an attachment (id=10134)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10134&action=view)
Preprocessed test case
This is not a designed test case, it's distilled from a real-world application
(
--- 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 #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 ch
--- 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-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
t 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-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22234
--- Additional Comments From falk at debian dot org 2005-06-29 16:49
---
Created an attachment (id=9173)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9173&action=view)
Test case (autoreduced)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22234
--- Additional Comments From falk at debian dot org 2005-07-02 10:17
---
(In reply to comment #4)
> The first call of pokus() completely ignores the assigned value of the
> variable
> r8 -- instead the value '6' into it for the call. The second call assumes th
--- Additional Comments From falk at debian dot org 2005-07-02 17:33
---
I see a difference here in that gcc doesn't know whether the referenced
object is declared to be volatile, it isn't visible as in PR 21568.
IMHO we actually have a bug here; I don't see anything
--- Additional Comments From falk at debian dot org 2005-07-02 17:53
---
(In reply to comment #5)
> Since the orginal pointer is not violatile the cast will not change any thing
since the compiler can
> deduce it is not violatile.
It could deduce that if it was invalid to
--- Additional Comments From falk at debian dot org 2005-07-02 20:38
---
According to Joseph Myers, the question is whether this counts as "access" to
a volatile object, which is implementation defined (6.7.3#6). However,
extend.texi doesn't answer this, so I&#x
--- Additional Comments From falk at debian dot org 2005-07-02 22:19
---
(In reply to comment #8)
> I can't imagine a programmer casting into a pointer to volatile without really
> meaning it, so if the behavior is not defined by the standard then both
> compatibility and
--- Additional Comments From falk at debian dot org 2005-07-02 23:45
---
(In reply to comment #19)
> How about this?
>
> int foo;
> *(volatile int*) (&foo);
>
> In other words, why should the compiler bother at all with the qualifiers of
> what the p
--- Additional Comments From falk at debian dot org 2005-07-04 09:36
---
This is fixed in 4.0, where one gets a warning (not an error) independent of
whether there was a previous declaration. Since it could even be argued
that erroring out is OK (although then it should be consistent
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: falk at debian dot org
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
--- Additional Comments From falk at debian dot org 2005-07-05 15:52
---
Created an attachment (id=9206)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9206&action=view)
test case (use -O)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22310
--- Additional Comments From falk at debian dot org 2005-07-06 09:53
---
It would be really helpful if you said what you expected, and what you got,
and whether you can reproduce this with another target.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22321
--- Additional Comments From falk at debian dot org 2005-07-06 12:11
---
(In reply to comment #2)
> With -O1 (which implies -ftree-dominator-opts) main returns -1.
> With -O1 -fno-tree-dominator-opts main returns 0.
>
> Do you really think that this bug is target specific
--- Additional Comments From falk at debian dot org 2005-07-06 22:59
---
This comes from feeding garbage to an asm:
void f(int x) {
__asm__ ("frob %w0" : "=r" (x));
}
Hmm. I'm not really sure it's worthwhile to generate a useful error message
for ever
--- Additional Comments From falk at debian dot org 2005-07-10 09:00
---
"as" is part of binutils, so please report it there. They will probably also
want the actual assembly file, which you can obtain by adding -save-temps.
--
What|Removed
--- Additional Comments From falk at debian dot org 2005-07-12 22:27
---
(In reply to comment #0)
> Instead of generating the code to store a byte using unaligned load/store
> instruction it uses aligned LDL/STL. The assembler code looks correct using
> -O0
> optimizat
--- Additional Comments From falk at debian dot org 2005-07-12 22:59
---
(In reply to comment #4)
> Unfortunatelly, with switching to gcc 4.x some code started to
> produce such exceptions (with gcc 3.4 everything was fine). Is there
> an option to make gcc think that passed
--- Additional Comments From falk at debian dot org 2005-07-14 13:19
---
(In reply to comment #2)
> This is invalid and here is why, if both p and x are NULL/0, then p+x will
always be NULL so in this is
> invalid optimization.
Huh? nullpointer + 0 is undefined, it doesn't
--- Additional Comments From falk at debian dot org 2005-07-14 13:45
---
(In reply to comment #4)
> H.
> I swear we just had this discussion for VRP purposes, and that a bug was
> recently fixed so that we don't assume that pointer + - integer is NULL.
Well, I che
--- Additional Comments From falk at debian dot org 2005-07-14 15:37
---
(In reply to comment #7)
> I'm failing to find anything in the C++ standard that suggests that the
> following shall be undefined
>
>(reinterpret_cast(0) + 5) - 5
If (reinterpret_cast(0
--- Additional Comments From falk at debian dot org 2005-07-14 21:47
---
Subject: Re: pointer +- integer is never NULL
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
> "falk at debian dot org" <[EMAIL PROTECTED]> writes:
>
> | --- Additional Comme
--- Additional Comments From falk at debian dot org 2005-07-15 06:41
---
Subject: Re: pointer +- integer is never NULL
"gdr at integrable-solutions dot net" <[EMAIL PROTECTED]> writes:
> My indirect observation was that reinterpret_cast is intended for
> spec
--- Additional Comments From falk at debian dot org 2005-07-15 14:22
---
(In reply to comment #13)
> Subject: Re: pointer +- integer is never NULL
>
> "falk at debian dot org" <[EMAIL PROTECTED]> writes:
> | Sorry, I cannot follow you. I'd
--- Additional Comments From falk at debian dot org 2005-07-15 15:05
---
(In reply to comment #18)
> The "side" notes were written by people who know what they
> intend. Therefore their inputs are completely relevant here.
This is going nowhere. I give up.
--
ht
--- Additional Comments From falk at debian dot org 2005-07-15 19:53
---
(In reply to comment #9)
> I cannot seems to find a way to generate traps on overflow.
-ftrapv does not trigger on overflowing calculations that are compile-time
constant. I am unsure whether this is a bug o
--- Additional Comments From falk at debian dot org 2005-07-16 20:25
---
I can't reproduce this with 4.1.0 20050716 on alphaev67. Can you please attach
the preprocessed source of traditional.c?
--
What|Removed |
erity: normal
Priority: P2
Component: tree-optimization
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: alph
--
Bug 19721 depends on bug 16961, which changed state.
Bug 16961 Summary: Poor x86-64 performance with 128bit ints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16961
What|Old Value |New Value
-
--- Additional Comments From falk at debian dot org 2005-07-19 14:12
---
The unrolling part of the report was moved to PR 16962, and the 128-bit part is
fixed, so closing.
--
What|Removed |Added
--- Additional Comments From falk at debian dot org 2005-07-29 22:20
---
waiting for testcase...
--
What|Removed |Added
Status|UNCONFIRMED
--- Additional Comments From falk at debian dot org 2005-07-30 13:35
---
Well, the behavior is undefined here, so what we currently do is just fine.
Moreover, this can only be detected at link time, so there's no way for us to
give a warning; at best, we could emit a fake referenc
--- Additional Comments From falk at debian dot org 2005-07-31 12:59
---
Can you please try with a newer compiler, preferably 4.0.1? The 3.3 branch
is closed. If you can then still reproduce it, please attach the preprocessed
source.
--
What|Removed
--- Additional Comments From falk at debian dot org 2005-07-31 13:31
---
(In reply to comment #4)
> What about permitting this as a GNU extension? It seems quite useful for
> template code.
With "this" you mean omitting the definition? Well, it saves one line of
typ
erity: normal
Priority: P2
Component: tree-optimization
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-
--- Additional Comments From falk at debian dot org 2005-08-01 11:56
---
(In reply to comment #2)
> This is a duplicate of PR 19899.
> There are several loops in the testcase with a floating-point loop variable
> and a test >= 0. Removing them makes the code compile.
Are
: 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-unknown-linu
101 - 200 of 320 matches
Mail list logo
