--- Comment #2 from dorit at il dot ibm dot com 2006-02-19 08:50 ---
This happens because we actually rely on dce taking place after the vectorizer
to clean up dead code. When we detect a pattern (widneing-summation in this
case) we create a dummy stmt (pattern-stmt) that represents the
--- Comment #9 from steven at gcc dot gnu dot org 2006-02-19 09:13 ---
I have no idea yet what's happening here, but I'm going to find out...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2006-02-19 12:54 ---
Then you can report the problem again when you've isolated it.
Please stop filing bug reports that are nothing but remarks, without test cases
or any analysis. Read http://gcc.gnu.org/bugs.html, you obviously still
--- Comment #10 from steven at gcc dot gnu dot org 2006-02-19 13:41 ---
I modified the test case a bit to make it easier to understand what is going
on:
void
do_sort (int *lst, int cnt)
{
int i, j, k;
for (i = 0; i cnt - 1; i++)
{
for (j = i + 1; j cnt; j++)
{
--- Comment #11 from steven at gcc dot gnu dot org 2006-02-19 13:42 ---
At least related to register allocation.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
% ../configure --enable-languages=c nice make bootstrap
[...]
/src/gcc-2006.02.19/build/./prev-gcc/xgcc
-B/src/gcc-2006.02.19/build/./prev-gcc/
-B/usr/local/alphaev68-unknown-linux-gnu/bin/ -c -DHAVE_CONFIG_H -g -O2 -I.
-I../../libiberty/../include -W -Wall -pedantic -Wwrite-strings
gfortran-autovect -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/local/autovect
--program-suffix=-autovect --enable-threads=posix
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.2.0-autovect 20060214 (experimental)
--- Comment #3 from pault at gcc dot gnu dot org 2006-02-19 15:24 ---
Subject: Bug 25054
Author: pault
Date: Sun Feb 19 15:24:26 2006
New Revision: 111268
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111268
Log:
2005-02-19 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #1 from pault at gcc dot gnu dot org 2006-02-19 15:24 ---
Subject: Bug 25089
Author: pault
Date: Sun Feb 19 15:24:26 2006
New Revision: 111268
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111268
Log:
2005-02-19 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #2 from dorit at il dot ibm dot com 2006-02-19 15:34 ---
The problem is that during dce the call to is_hidden_global_store returns false
cause the tag is not marked as global/static.
This seems to fix it:
Index: tree-ssa-alias.c
--- Comment #1 from falk at debian dot org 2006-02-19 15:34 ---
Apparently, it is triggered by the attempt to emit a stack probe, as in:
void f(char *p);
void md5_stream(void) {
char buf[4096-15];
f(buf);
}
(doesn't happen with 4096-16, because then no stack probe is needed).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||build, ice-on-valid-code,
|
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-19 15:38 ---
I wonder if this is related to at all PR 26348.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from falk at debian dot org 2006-02-19 15:57 ---
(In reply to comment #2)
I wonder if this is related to at all PR 26348.
Probably not, because it already happens without any options (forgot to mention
that).
--
falk at debian dot org changed:
What
--- Comment #10 from dorit at il dot ibm dot com 2006-02-19 16:10 ---
so maybe if an SFT has may-aliases then new_type_alias should add the
may-aliases of the SFT as may-aliases of the new tag, instead of adding the SFT
as a may-alias of the new tag. ?
There's a comment in
--- Comment #4 from pault at gcc dot gnu dot org 2006-02-19 16:24 ---
Fixed on trunk - ready for 4.1 just as soon as it reopens.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pault at gcc dot gnu dot org 2006-02-19 16:26 ---
Fixed on trunk - ready for 4.1 as soon as it reopens.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-02-19 16:30 ---
[11:22] mellum The Alpha bootstrap bug seems to be due to
alpha_expand_prologue being miscompiled
[11:23] mellum there's a loop
[11:24] mellum for (probed = 4096; probed frame_size; probed += 8192) {
[11:24]
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-02-19 16:38 ---
You need to add an initializer to make
template int DataV1::Value;
a definition. Otherwise it's just an explicit specialization decl. Or
if you do not want to specialize for V1, use
template V v int
--- Comment #5 from vz-gcc at zeitlins dot org 2006-02-19 16:50 ---
In reply to comment 4: I do realize that adding an initializer fixes the
problem. But what to do if the static member is an object of a class which only
has a default ctor? E.g.
enum V { V1, V2, V3 };
struct Int {
--- Comment #9 from eedelman at gcc dot gnu dot org 2006-02-19 17:23
---
Subject: Bug 26201
Author: eedelman
Date: Sun Feb 19 17:23:07 2006
New Revision: 111270
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111270
Log:
fortran/
2006-02-19 Erik Edelmann [EMAIL PROTECTED]
--- Comment #5 from falk at debian dot org 2006-02-19 18:19 ---
The problem apparently comes from using negation on an induction variable,
in a context where widening is needed:
[EMAIL PROTECTED]:/tmp% cat alpha.c
void abort(void);
int printf(const char *format, ...);
--- Comment #6 from steven at gcc dot gnu dot org 2006-02-19 18:56 ---
Also fails on AMD64.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from tobi at gcc dot gnu dot org 2006-02-19 18:56 ---
I might be a little late, given that you already posted a patch which
completely fixes this issue
http://gcc.gnu.org/ml/fortran/2006-02/msg00420.html, but I thought of fixing
this back before we had the in_equivalence
--- Comment #7 from falk at debian dot org 2006-02-19 18:58 ---
not really ice-on-valid-code nor memory-hog, those were only due to miscompiled
xgcc
--
falk at debian dot org changed:
What|Removed |Added
--- Comment #4 from paulthomas2 at wanadoo dot fr 2006-02-19 19:25 ---
Subject: Re: Dependency checking fails for equivalences
tobi,
--- Comment #3 from tobi at gcc dot gnu dot org 2006-02-19 18:56 ---
I might be a little late, given that you already posted a patch which
--- Comment #10 from mmitchel at gcc dot gnu dot org 2006-02-19 19:31
---
Subject: Bug 26350
Author: mmitchel
Date: Sun Feb 19 19:31:22 2006
New Revision: 111276
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111276
Log:
PR target/26350
* config/rs6000/rs6000.md
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-02-19 19:36 ---
This looks more related to PR 26304.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-02-19 19:50
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
If I have listed every possible case for a switch, there is no need for a
default. The compiler generates this default anyway though, even if I don't
specify it. I'd like a way to eliminate this, such that an unhandled case
becomes undefined behavior that may well involve a crash.
(the same
--- Comment #9 from jakub at gcc dot gnu dot org 2006-02-19 20:01 ---
Subject: Bug 26334
Author: jakub
Date: Sun Feb 19 20:01:26 2006
New Revision: 111279
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111279
Log:
PR middle-end/26334
* gcc.dg/20060218-1.c: Moved
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26291
Gcc 4.1/4.2 generates wrong DWARF info when it fails to inline a static
function.
--
Summary: [4.1/4.2 regression]: Uninlined function is marked as
inlined
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 20:13 ---
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26364
--- Comment #2 from hjl at lucon dot org 2006-02-19 20:15 ---
Created an attachment (id=10877)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10877action=view)
A testcase
This is the preprocess Linux kernel code for gcc 4.1 and 4.2. There are many
static functions, like pageout,
--- Comment #1 from tobi at gcc dot gnu dot org 2006-02-19 20:15 ---
Confirmed, I think Paul Thomas is looking into this.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
incorrect code gives ICE
--
Summary: ICE in finish_class_member_access_expr, at cp/typeck.c
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-19 20:18 ---
Next time don't attach a tar ball, please.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26364
I can't tell if it would be useful to do this:
x = get_x();
__builtin_expect(xMASK,KNOWNBITS);
__builtin_expect(x=KNOWNMAX,1);
__builtin_expect(x=KNOWNMIN,1);
// code which uses x would follow this
Given two booleans that are 2/3 likely, the chance of both is 4/9 likely. So
maybe it is
--- Comment #1 from cees at pcraster dot nl 2006-02-19 20:25 ---
Created an attachment (id=10878)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10878action=view)
the source giving the ICE
g++ -c calc_astsymbolinfo.ii
gives the ICE,
g++ --version:
g++ (GCC) 4.0.3 20060212
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 20:25 ---
I thought the documention said only to use __builtin_expect when you know that
in almost 100% of the time it is going to be true (or false).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26366
My expectation may be:
a. certain (OK if the code crashes when I lie)
b. strong
c. weak
This could be expressed as an optional 3rd argument to state the estimated
probability. Alternately, stuff like __builtin_expect_strongly() could be used.
I'd like to use this to inform gcc that certain bit
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2006-02-19 20:31
---
Final patch waiting for review/approval:
http://gcc.gnu.org/ml/fortran/2006-02/msg00421.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26136
Something used roughly like this:
unsigned foo __attribute__((
min(5), // value will never be below this
max(0x007fff04), // value will never be above this
set(0x0004), // these bits will always be set
clear(0xff82), // these bits will never be set
likely_min(100), // the
I think an anon union or struct ought to work at top level or in any block.
It's nice for data layout, to reduce cache footprint, page faults, etc.
Here is a silly example:
union {
int i;
float f;
};
int foo(arg){
f = arg;
return i;
}
--
Summary: anon union/struct at top
A large project may have a configurable build to allow optional features. Fully
eliminating a feature may require #ifdef all over the place, making the code
ugly and unmaintainable. Example: you want an OS kernel to support an embedded
systems build that lacks the normal user ID handling.
If
This would be for char of course.
When -fno-strict-aliasing is in effect, the proposed attribute should be able
to reenable strict aliasing for any type.
--
Summary: opposite of may_alias attribute
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-02-19 21:31
---
Subject: Bug 21303
Author: fxcoudert
Date: Sun Feb 19 21:31:02 2006
New Revision: 111281
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111281
Log:
PR libfortran/21303
* gfortran.h
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 21:31 ---
__restrict it is called.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26372
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Summary|Positive width required in |[4.1 only] L edit descriptor
|format string
# gcc -O1 z.adb
+===GNAT BUG DETECTED==+
| 3.3.5 (Debian 1:3.3.5-13) (i486-pc-linux-gnu) Gigi abort, Code=116 |
| Error detected at crypto-types-big_numbers.ads:309:41|
| Please submit a bug report; see
--- Comment #2 from acahalan at gmail dot com 2006-02-19 21:40 ---
No, __restrict is too strong. It also, last I heard, couldn't be applied to a
type.
(if restrict was right, then using it on an int would be redundant)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26372
--- Comment #31 from mueller at gcc dot gnu dot org 2006-02-19 21:42
---
I see many false positives and negatives with the -Warray-bounds patch. I
haven't closely investigated the false positives yet, but one of the false
negatives is this:
=== Cut ===
struct bla {
bla();
int*
--- Comment #1 from crypto at shortie dot inka dot de 2006-02-19 21:43
---
Created an attachment (id=10879)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10879action=view)
This tar archive contains source code to trigger the bug
--
--- Comment #2 from acahalan at gmail dot com 2006-02-19 21:48 ---
Nope, at least if the documentation at
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html is what you refer to.
It would be good to document how strong the expectation is for each
architecture. Apparently the
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-19 21:48 ---
Reducing (that means I can reproduce this ICE).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26365
=== Cut ===
static const double coeff[] = { 1.0l/42 };
=== Cut ===
gives:
testcase.c:1: error: initializer element is not constant
testcase.c:1: error: (near initialization for #8216;coeff[0]#8217;)
--
Summary: Compile failure on long double
Product: gcc
--- Comment #2 from laurent at guerby dot net 2006-02-19 22:01 ---
Confirmed present on 4.0, 4.1, 4.2.
$ gcc -c z.adb
+===GNAT BUG DETECTED==+
| 4.0.2 (i686-pc-linux-gnu) in gnat_to_gnu_entity, at ada/decl.c:287 |
| Error
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 22:01 ---
This is actually because the middle-end does not constant fold 128bit IBM long
double. I am assuming you are using -mlong-double-128.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from falk at debian dot org 2006-02-19 22:02 ---
In the past, it has been de-facto gcc policy to add only language extensions
that do something that fundamentally cannot be done in ISO C. So it would be
quite unlikely that this would be accepted. In addition to that, I
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-19 22:02 ---
Which is PR 19779.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-02-19 22:03 ---
I'm not sure 1.0l/42 is a valid constant initializer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mueller at gcc dot gnu dot org 2006-02-19 22:04 ---
yes, full configure line:
Target: powerpc64-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr
--with-local-prefix=/usr/local --infodir=/usr/share/info
--mandir=/usr/share/man
--- Comment #5 from mueller at gcc dot gnu dot org 2006-02-19 22:20 ---
hmm, I guess I'm find with resolving this as duplicate to 19779, even though I
don't understand why this is only an issue on PPC for me..
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26374
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-19 22:24 ---
(In reply to comment #5)
hmm, I guess I'm find with resolving this as duplicate to 19779, even though I
don't understand why this is only an issue on PPC for me..
It is because the long double format used on PPC
--- Comment #10 from jakub at gcc dot gnu dot org 2006-02-19 22:36 ---
Subject: Bug 26334
Author: jakub
Date: Sun Feb 19 22:36:39 2006
New Revision: 111285
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111285
Log:
PR middle-end/26334
* gcc.dg/20060218-1.c: Moved
--- Comment #9 from falk at debian dot org 2006-02-19 22:46 ---
This bug was introduced with:
r75 | law | 2006-02-17 05:15:32 +0100 (Fri, 17 Feb 2006) | 33 lines
* tree-vrp.c (set_value_range_to_nonnegative): New function.
(vrp_expr_computes_nonnegative,
--- Comment #2 from acahalan at gmail dot com 2006-02-19 23:02 ---
Given that we have anon unions, and given that unions can exist at top level
and function level, this is a very logical extension. It lifts an annoying and
arbitrary restriction.
From the user's point of view, this
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-19 23:06 ---
Reduced testcase:
class Exchange{ };
struct optional
{
Exchange const* operator- () const {}
};
namespace pcrxsd {
template typename T, typename V inline T fundamentalBaseCast() { }
void setInfo(optional a)
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26369
--- Comment #3 from acahalan at gmail dot com 2006-02-19 23:09 ---
Here is an example of something that fundamentally can not be done in plain C.
Suppose I have a large project with a badly-named global variable. When I
compile with -Wshadow, I get lots of complaints. I'd like to
--- Comment #4 from acahalan at gmail dot com 2006-02-19 23:20 ---
Here is an example of something that is seriously awkward to do in C.
Suppose I want to ensure that several variables end up in the same cache line.
I'd like to do it this way:
struct {
short s1;
short s2;
--enable-targets=powerpc64-linux
--enable-languages=c,c++,fortran --prefix=/home/anton/toolchain/install
Thread model: posix
gcc version 4.2.0 20060219 (experimental)
$ cat foo.c
unsigned int foo(unsigned int code, int len)
{
unsigned int res = 0;
do {
res |= code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 00:25 ---
Confirmed, this worked with 4.2.0 20060127 and does not with 4.2.0
20060218.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 00:26 ---
Nothing changed on the tree level with this loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26375
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 00:31 ---
Janis can you do a regression hunt for this bug?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from sayle at gcc dot gnu dot org 2006-02-20 00:34 ---
Subject: Bug 19543
Author: sayle
Date: Mon Feb 20 00:34:12 2006
New Revision: 111294
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=111294
Log:
PR middle-end/19543
* varasm.c
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 02:02 ---
Can you show an example how to use these variables? I don't understand why you
cannot use if(TARGET_WANTS_XXX)
instead of #if TARGET_WANTS_XXX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26371
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 02:04 ---
Can you give an example of where this is useful and why not instead improve GCC
for your code gen issues?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26372
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 02:06 ---
x86 is forgiving because there is no such bit that is used (well except for the
prescott and GCC disables it because it was a wash and used up space).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26366
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 02:09 ---
I don't understand why this is useful really as GCC now has VRP which will find
most of this information and remove code which is useless.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26369
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-20 02:10 ---
GCC now has theories about extensions, dont' add them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26370
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 02:13 ---
I don't see why there needs to be an attribute or even cause that much missed
optimization? GCC should be able to find that the default is not taken via VRP
but does not currently but that is a different bug that
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26364
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 02:15 ---
Can you give an example of why you need these builtins?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-20 02:24 ---
Hmm, natStackTrace.cc was removed with:
2005-03-10 Bryce McKinlay [EMAIL PROTECTED]
New Stack Trace infrastructure.
So maybe this has been fixed for 4.1.0.
Also are you sure that it is leaking or just
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-02-20 02:26 ---
/tmp/cco53Air.o: In function `_start': relocation truncated to fit: GPRELHIGH
Are you sure that this is not a binutils bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26347
--- Comment #10 from roger at eyesopen dot com 2006-02-20 03:11 ---
Analyzing the code in comment #5, this looks like a bad interaction between
ivopts and vrp. Either of -fno-ivopts or -fno-tree-vrp cures the problem.
But it looks like the output of .084t.ivopts is reasonable.
--
--- Comment #2 from acahalan at gmail dot com 2006-02-20 03:18 ---
For variables that are commonly used in a large project, you sure wouldn't want
to be putting conditional code all over the place if you could avoid it. The
choice could be something like:
a. put #if TARGET_WANTS_XXX in
--- Comment #4 from acahalan at gmail dot com 2006-02-20 03:29 ---
There have been times when I could not prove to myself that __restrict would be
safe (it may have been), yet I knew that the char pointer would not alias with
non-char pointers.
(sorry to not have a nice chunk of code
--- Comment #2 from acahalan at gmail dot com 2006-02-20 03:49 ---
I gave two examples. (you may assume I want code to run fast)
I first saw this feature proposed on the linux-kernel mailing list when there
was some argument over whether or not __builtin_expect() should be used in a
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-20 03:51 ---
Oh, did I forgot __builtin_expect gives the same probability on all targets,
just some use it more than others.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26367
--- Comment #11 from roger at eyesopen dot com 2006-02-20 03:52 ---
Hmmm. Looks like the problem is in .088t.vrp2
We have
unsigned int D.1981;
unsigned int D.1982;
D.1982_9 = -D.1981_1;
D.1981_1: [0, +INF] EQUIVALENCES: { } (0 elements)
D.1982_9: [0, 1] EQUIVALENCES: { } (0
--- Comment #2 from acahalan at gmail dot com 2006-02-20 04:00 ---
VRP (value range propagation, if I guess right) doesn't always have the data it
needs. Commonly, people split projects into multiple files and do not use
-fwhole-program to compile the project. This seems to be the norm
--- Comment #13 from roger at eyesopen dot com 2006-02-20 04:10 ---
Many thanks to Mark, Richard and David! This is now fixed on both mainline and
the gcc-4_1-branch in time for the 4.1 release. On mips-sgi-irix6.5, for the
4.1 branch I now see the following (which is much better than
--- Comment #4 from acahalan at gmail dot com 2006-02-20 04:11 ---
It's interesting that you say __builtin_expect gives the same probability on
all targets. I'm not exactly sure what you mean, but I'll guess that you mean
it states that the condition will be true X% of the time.
If so,
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-02-20 04:58
---
Here is a testcase independent of IV-OPTs:
void abort(void);
int printf(const char *format, ...);
__attribute__((noinline))
void gen_rtx_CONST_INT(long long x) {
if (-x 10)
abort();
}
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-02-20 04:59
---
I forgot to mention with my reduced non ivopts depending testcase this makes
this indepenent of those two bugs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-20 05:00
---
Also forgot to mention my testcase is indepenent of 64 bitness of the target.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-02-20 05:09
---
With my reduced testcase (well s/long long/long/), we get:
D.1552_8 = -a_7;
a_7: [0, +INF] EQUIVALENCES: { } (0 elements)
D.1552_8: [0, 1] EQUIVALENCES: { } (0 elements)
on the mainline, while in 4.1.0 we
1 - 100 of 105 matches
Mail list logo
