--- Additional Comments From rth at gcc dot gnu dot org 2005-02-13 09:29
---
Actually, I misread the function I was supposed to be looking for loops in.
We do in fact vectorize 21 loops in beam_stress_integration. So... WORKSFORME.
--
What|Removed
2005-02-12, the link error is known on mips{,el}-linux, first time I see it on
alpha-linux as well.
Matthias
Creating list of files to link...
/bin/sh ./libtool --tag=CXX --mode=link
/build/buildd/gcc-snapshot-20050212/build/gcc/xgcc -shared-libgcc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-13
10:25 ---
Subject: Bug 11706
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-13 10:25:02
Modified files:
libstdc++-v3 : ChangeLog
--- Additional Comments From pcarlini at suse dot de 2005-02-13 10:26
---
Fixed for 4.0.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
I have a simple testcase:
void test()
{
}
# arm-linux-gcc test.c -S -O2 produces:
test:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
@ lr needed for prologue
$ cat implied_parameter.f90
program main
integer, parameter :: i=4
print *,(/(i,i=1,4)/)
end program main
$ gfortran implied_parameter.f90
In file implied_parameter.f90:3
print *,(/(i,i=1,4)/)
1
Error: Syntax error in COMPLEX constant at (1)
$ gfortran -v
Using built-in
--- Additional Comments From ciceron at gcc dot gnu dot org 2005-02-13
11:16 ---
The compiler crashes because the GCSE pass generates an invalid insn:
(insn 138 10 108 0 (nil) (set (reg:SI 61)
(reg/v:SI 55)) -1 (nil)
(nil))
and this is caused by handle_avail_exp() which
--- Additional Comments From ciceron at gcc dot gnu dot org 2005-02-13
11:42 ---
I'm not able to reproduce the problem neither on 3.3.5 nor on 3.4 branch.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-13
11:52 ---
This is now fixed on the PA. You might look at pa-host.c to if the
adopted work around might help other ports.
Alas, that doesn't work on SPARC/Solaris.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-13
12:49 ---
Subject: Bug 19319
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-13 12:49:34
Modified files:
libmudflap : ChangeLog
Added files:
--- Additional Comments From fche at redhat dot com 2005-02-13 12:50
---
Thank you, Jason!
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From schwab at suse dot de 2005-02-13 13:12 ---
I have successfully bootstrapped gcc and glibc with this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19917
--
What|Removed |Added
Component|preprocessor|target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
13:55 ---
Confirmed.
See http://gcc.gnu.org/ml/java-patches/2005-q1/msg00323.html for a possible
patch and
discussion.
--
What|Removed |Added
--
What|Removed |Added
Component|regression |target
Summary|unexpected bx lr in arm |[4.0 Regression] unexpected
|mode.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
14:11 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From kazu at cs dot umass dot edu 2005-02-13 14:17
---
The testcase in this PR was reduced from ggc-page.c:ggc_alloc_typed_stat.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19792
--- Additional Comments From mueller at kde dot org 2005-02-13 14:59
---
bug has been fixed by
2005-02-13 Jason Merrill [EMAIL PROTECTED]
PR mudflap/19319
* gimplify.c (gimplify_modify_expr_rhs) [CALL_EXPR]: Make return
slot explicit.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
15:40 ---
(In reply to comment #7)
it seems to me however the above commit caused another regression, I get
other miscompilations now.
More than just that it causes a bootstrap to fail (I think you must have
$ cat loop.c
typedef __SIZE_TYPE__ size_t;
extern void abort (void);
extern size_t strlen (const char *);
extern int strncmp (const char *, const char *, size_t);
int foo (const char *name)
{
static const char *debug_sec_names [] =
{
.debug,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
16:25 ---
Confirmed, looking for where it is miscompiled.
--
What|Removed |Added
CC|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
16:44 ---
Reduced testcase:
void abort (void);
int g(void)
{
return 1;
}
int main (void)
{
int i;
for (i = 4; i--;)
if (g () == 0)
break;
if (i = 0)
abort ();
return 0;
}
--- Additional Comments From phython at gcc dot gnu dot org 2005-02-13
16:45 ---
Fixed in the last patch.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
16:52 ---
I think this is an ivopt bug:
if (i_3 != 4294967295) goto L0; else goto L10;
i_3 is signed but the expression (I think), 4294967295, is unsigned, maybe we
are missing a
fold_convert.
--
--- Additional Comments From giovannibajo at libero dot it 2005-02-13
17:25 ---
Andy, the patch needs a ChangeLog and needs to be posted to gcc-patches. I
suggest you to explicitly CC the AVR maintainers when you post the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18251
Tim Janik wrote:
hi all.
the code snippet below is extracted from a much more
complicated piece of code. basically the problem is that
g++ (3.3 and 3.4) demand different typedef syntax inside
template bodies, depending on whether full or partial
specialization is used.
is this really the correct
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-13
17:50 ---
Looking at PR 17123 a bit more closely, I think that
this is a duplicate.
Thomas
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19928
Consider:
void
foo (int length, int *array)
{
int i;
for (i = 0; i length; i++)
{
if (array[i] != 0)
{
int j;
for (j = 0; j length; j++)
;
if (j != length)
array[i] = 0;
}
}
}
A part of the last tree SSA
--
What|Removed |Added
BugsThisDependsOn||19938
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19721
--
What|Removed |Added
BugsThisDependsOn||19938
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
--- Additional Comments From sgk at troutmask dot apl dot washington dot
edu 2005-02-13 18:00 ---
For a long winded explanation and patch, see
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00643.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19936
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
18:04 ---
Confirmed, but note the following in the tree level is really invalid:
D.1187_17 = (unsigned int) length_4;
if (j_16 != D.1187_17) goto L2; else goto L4;
as j_16 is signed and we are comparing against
[EMAIL PROTECTED]:/tmp% cat test.c
unsigned long ipow(unsigned long a, unsigned long b) {
if (b == 0)
return 1;
else
return a * ipow(a, b - 1);
}
[EMAIL PROTECTED]:/tmp% gcc -c -O2 test.c objdump -d test.o
test.o: file format elf64-alpha
Disassembly of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
18:17 ---
This is a dup of bug 1046, yes the function is slightly different but the
problem is the same:
Well at -O3 -fno-inline this is fixed but at -O3 -finline this is not fixed,
the problem is that
fib is
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
18:17 ---
*** Bug 19939 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From schlie at comcast dot net 2005-02-13 18:30
---
(In reply to comment #1)
There has to be a reason why we want to use long int instead of the integer
type which is the same size
There's no doubt that someone may have thought so, but it's wrong;
as there's
Consider:
void bar (void);
int global;
void
foo (unsigned char pedwarned, unsigned char warned)
{
unsigned char tem = warned | pedwarned;
if (tem == 0)
{
if (global)
warned = 1;
}
tem = warned | pedwarned;
if (tem != 0)
bar ();
}
Notice that if we get to
--
What|Removed |Added
BugsThisDependsOn||19940
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
When there are many nested switch statements, then the compiler does not
recognize bogus labels such as spelling mistakes like 'delault' instead of
'default', and goes on to generate code. Even with -Wall, no warning is
generated. However these stupidities(spelling mistakes) are recognized and
--- Additional Comments From dhruvbird at yahoo dot com 2005-02-13 18:40
---
Created an attachment (id=8190)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8190action=view)
The files required for reproducing the bug, and a short description.
--
--- Additional Comments From dhruvbird at yahoo dot com 2005-02-13 18:44
---
(In reply to comment #1)
Created an attachment (id=8190)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8190action=view)
The files required for reproducing the bug, and a short description.
Actually,
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
18:50 ---
Labels inside a switch statement is legal code and it is hard to dect that you
had ment to use default
instead of what you put in the label. (default is just a special label really).
Use
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
18:59 ---
Confirmed, related to PR 18832.
Note on PPC at least we don't really thread the jumps that well on the rtl
level:
_foo:
or. r0,r4,r3
bne- cr0,L2
lis r2,ha16(_global)
ori
/ali.adb -o
ada/ali.o
+===GNAT BUG
DETECTED==+
| 4.0.0 20050213 (experimental) (powerpc-apple-darwin7.8.0) GCC error: |
| in gnat_type_for_mode, at ada/utils.c:1838 |
| Error detected at ali.adb:2097:1
--- Additional Comments From schwab at suse dot de 2005-02-13 19:17 ---
Broken by this patch:
2005-02-06 Zdenek Dvorak [EMAIL PROTECTED]
* tree-ssa-loop-ivopts.c (rewrite_use_nonlinear_expr): Do not add
unnecessary cast to original induction variable increments.
--
What|Removed |Added
Keywords||ice-on-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19942
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
19:24 ---
Mine, I am about to submit the patch to fix this bug.
--
What|Removed |Added
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
19:38 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00646.html.
--
What|Removed |Added
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-02-13
19:50 ---
Function that may trap is not pure; in particular func_pure_2 cannot
be considered pure. The remaining testcases are real bugs, however.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19828
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-13 20:05
---
That's a pretty useless definition of pure functions - they may read global
memory, but not dereference any pointers which are invalid at any point in
the life of the program?
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-13
20:08 ---
Subject: Bug 19942
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-13 20:08:29
Modified files:
gcc/ada: ChangeLog utils.c
Log message:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
20:09 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-02-13 20:11 ---
Subject: Re: [4.0 Regression] LIM is pulling out a pure function even though
there is something which can modify global memory
That's a pretty useless definition of pure functions -
--- Additional Comments From drow at gcc dot gnu dot org 2005-02-13 20:13
---
I've suggested when talking to someone else about this that they should be
assumed not to trap at the points where they are called. That would allow
calls to them to be removed, although still limit code
--- Additional Comments From ian at airs dot com 2005-02-13 20:27 ---
The definition of pure states that such a function may depend upon global
variables. I guess you are saying that func_pure_2 is not pure because the
global variable a may not be a valid memory address?
I disagree.
--- Additional Comments From joseph at codesourcery dot com 2005-02-13
20:38 ---
Subject: Re: [4.0 Regression] LIM is pulling
out a pure function even though there is something which can modify global
memory
On Sun, 13 Feb 2005, drow at gcc dot gnu dot org wrote:
I've suggested
code below produces memcpy invocation for wrong_1 and wrong_2 procedures, only
ok procedure hets memcpy optimized properly.
Both wrong_1 and wrong_2 should compile to identical code equal to code of ok.
--begin code--
include string.h
char *b;
struct W {
inline static void wr(char *buf, int
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
20:56 ---
Fixed in 4.0 by doing some const progation before expanding to RTL.
A way to get around this before 4.0 you can declare sz as constant aka:
inline static void wr(char *buf, const int sz)
--
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-02-13
20:56 ---
Patch posted here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00653.html
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-13
21:24 ---
...and the hammer branch does not fail this test case because it has Zdenek's
patch on it. Well, that explains - and gives me some more confidence to
submit it for GCC 4.0 too.
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-13
21:31 ---
Subject: Bug 19019
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-13 21:31:37
Modified files:
gcc: ChangeLog
--- Additional Comments From w dot northcott at unsw dot edu dot au
2005-02-13 22:55 ---
This is a documentation problem.The current host specific docs at
http://gcc.gnu.org/install/
specific.html#alpha*-*-* read:
*
In Tru64 UNIX V5.1, Compaq introduced
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
23:03 ---
In fact I just tested the patch for PR 19937 and it fixes this bug also.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-13
23:14 ---
Moving to 4.1 as I don't care much if this gets fixed.
--
What|Removed |Added
Target
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-13
23:44 ---
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00655.html
--
What|Removed |Added
Between LAST_UPDATED and these tests were introduced,
failing from the start for cris-elf:
FAIL: gcc.dg/pr15784-1.c scan-tree-dump-times ABS_EXPR 0
FAIL: gcc.dg/pr15784-2.c scan-tree-dump-times ABS_EXPR 0
The top of pr15784-1.c.t03.generic is:
a (x)
{
int D.1055;
int D.1056;
D.1056 =
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-14 00:17
---
Title change as it's not actually a regression; I haven't seem the tests pass.
--
What|Removed |Added
int a;
void foo(void)
{
a = 10;
}
when compiled with GCC 4.0 20050118, with -O2 -fomit-frame-pointer, generates
the following code:
foo:
movl$10, %eax
movl%eax, a
ret
Notice the unnecessary which wastes
--
What|Removed |Added
Severity|normal |critical
Known to fail||4.0.0
Known to work|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
00:19 ---
Looks like Jason accidently reverted the patch which fixed these.
--
What|Removed |Added
--
What|Removed |Added
Component|c |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19945
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
00:25 ---
Fixed since at least 20050127.
--
What|Removed |Added
Severity|critical
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
00:26 ---
Confirmed with yesterday's compiler (why it works with a cross to x86_64 and
-m32 I don't know).
--
What|Removed |Added
Between LAST_UPDATED Sat Feb 12 01:23:34 UTC 2005 and
Sun Feb 13 17:33:07 UTC 2005 I see testsuite regressions for
cris-elf:
FAIL: demangle/abi_examples/01.cc execution test
FAIL: demangle/abi_examples/02.cc execution test
There was a demangler cp_demangle.c change in this time-frame
(author
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
00:35 ---
This is not a regression at all, in fact on i686 it is cheaper to do the moves
instead of doing it in one
move.
So really this is not a bug at all. In fact my testing shows that this is not
really a
--- Additional Comments From giovannibajo at libero dot it 2005-02-14
00:36 ---
Seems deliberate, -march=i486 fixes it, so it is not a regression (my 3.4 was
configured to default to -march=i486). I don't see how wasting a register can
make the code faster on i686 though.
--
--- Additional Comments From giovannibajo at libero dot it 2005-02-14
00:37 ---
It is easy to devise a testcase where we run slower because of the additional
wasted register.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
00:43 ---
Then open one with that testcase as this as this is intentional as:
const int x86_split_long_moves = m_PPRO;
and PPRO is the same as i686 and pentiumpro.
--
What|Removed
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-14
00:49 ---
This is not wasting a register at all, don't make unfounded claims like that
if you don't know why exactly the code looks like it does.
In this case the code comes from a peephole2 splitting the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
01:58 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-14 02:00
---
Oops, forgot to fill in actual dates on the first line. Here for reference:
Between LAST_UPDATED Sat Feb 12 01:23:34 UTC 2005 and
Sun Feb 13 17:33:07 UTC 2005 these tests were introduced
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
02:21 ---
Fixed on the mainline now.
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
02:23 ---
Note the code from build_binop from the C and C++ front-ends need to be moved
to fold and then
when that happens my tree combiner will just work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14844
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Last reconfirmed|2004-11-15
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-14
02:27 ---
Subject: Bug 19944
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-14 02:27:33
Modified files:
gcc: fold-const.c ChangeLog
Log
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
02:33 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
02:42 ---
We hit a different ICE now:
gcc_assert (TREE_TYPE (rhs) == TREE_TYPE (lhs)
|| AGGREGATE_TYPE_P (TREE_TYPE (lhs)));
in gfc_add_modify_expr
--
I have some functions marked with this attribute, on most it works ok,
but sometimes I get:
sorry, unimplemented: inlining failed in call to 'my_func': function not
inlinable
sorry, unimplemented: called from here
And the second line doesn't seem to point to the use of this function at all.
Also
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
05:16 ---
A more complex example is fine for right now, it might be a duplicate of bug
14950 or PR 17248.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19947
--- Additional Comments From schlie at comcast dot net 2005-02-14 05:47
---
(In reply to comment #7)
Note the code from build_binop from the C and C++ front-ends need to be moved
to fold and then
when that happens my tree combiner will just work.
Sorry, but a little confused, as
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-14
05:57 ---
(In reply to comment #8)
Sorry, but a little confused, as it's perfectly correct to shorten these
operands to the width
of the operation's assignment, and in fact should be done? (so there's
nothing
--- Additional Comments From schlie at comcast dot net 2005-02-14 06:04
---
(In reply to comment #5)
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00657.html
it may be worth noting that compare for equivelence/non-equivelence,
is insensitive to the sign of equivelent rank integers,
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2005-02-14 07:03 ---
Subject: Re: [4.0 regression] Wrong loop exit
(In reply to comment #5)
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00657.html
it may be worth noting that compare for
--- Additional Comments From uros at kss-loka dot si 2005-02-14 07:03
---
The patch for the problem described in description of this bug is actually at
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01928.html. There is an
inconsistency in simplify_binary_operation(), as decribed in b).
ICE: tree check: expected class 'declaration', have 'exceptional' (error_mark)
in pushtag, at cp/name-
lookup.c:4658
g++ is very confused about forward-declared classes and friend classes.
--
GCC version info:
Using built-in specs.
Configured
96 matches
Mail list logo
