This PR was originally opened against PRE (PR25809), but turns out PRE can't
solve this problem, so here's a new PR instead:
In testcases that have reduction, like gcc.dg/vect/vect-reduc-2char.c and
gcc.dg/vect-reduc-2short.c, the following casts appear:
signed char sdiff;
--- Comment #8 from dorit at il dot ibm dot com 2007-05-09 07:14 ---
So I guess this should be handled somewhere else. I'll open a new
missed-optimization PR instead (not against PRE this time). thanks.
This is now PR31873
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25809
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-05-09 07:27
---
This testcase (gcc.dg/pr30957-1.c) fails on spu-elf because spu-elf's float
almost always treat -0.0 as 0.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30957
--- Comment #10 from jakub at gcc dot gnu dot org 2007-05-09 07:30 ---
You are entitled to your opinion.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-09 07:30 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
/home/apinski/src/local/gcc/gcc/testsuite/gcc.dg/torture/pr28900.c: In function
'synths_':^M
/home/apinski/src/local/gcc/gcc/testsuite/gcc.dg/torture/pr28900.c:5: internal
compiler error: in vect_transform_loop, at tree-vect-transform.c:5263^M
Please submit a full bug report,^M
with preprocessed
--- Comment #4 from steven at gcc dot gnu dot org 2007-05-09 07:06 ---
Investigating...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-09 07:33 ---
valgrind shows:
==7067== Syscall param write(buf) points to uninitialised byte(s)
==7067==at 0x5603550: write (in /lib64/libc-2.5.so)
==7067==by 0x4EC1130: do_write (unix.c:336)
==7067==by 0x4EC11D1:
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 07:35 ---
/home/apinski/src/local/gcc/gcc/testsuite/gcc.dg/torture/pr28900.c:8: note:
--vectorizing statement: L17:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Use GCJ as web plugin for java.
Go to http://www.runescape.com
Click Play as an existing user (No need to create user name)
Click High Definition
Click Free membership
There was an error before playing the game.
The error is Error loading applet
Currently using Fedora Core 6 on a 64-bit
--
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
Attached code fails to compile with cross compiler for sh4-linux.
$ sh-linux-gcc -m4 -c frame.i
frame.c: In function efaacEncSetConfigurationf:
frame.c:262: internal compiler error: in gen_lowpart_general, at rtlhooks.c:59
--
Summary: SH: ICE in gen_lowpart_general, at
--- Comment #1 from sugioka at itonet dot co dot jp 2007-05-09 10:10
---
Created an attachment (id=13533)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13533action=view)
pre-processed code
Source code which causes the problem.
--
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-09 10:47 ---
Does it do it if you specify --param lim-expensive=1? Then it's just a cost
issue.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from liqin at gcc dot gnu dot org 2007-05-09 10:55 ---
I will remove the bitclr_c,bitset_c and bittgl_c pattern
from misc.md, they have not to many use.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30987
--- Comment #2 from bkoz at gcc dot gnu dot org 2007-05-09 11:06 ---
I'm not quite sure if the component=c is correct. This could also be c++, or
driver.
This seems fine for the time being.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31864
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-05-09 11:10 ---
(In reply to comment #1)
Does it do it if you specify --param lim-expensive=1? Then it's just a cost
issue.
no, lim won't do this transformation. Store motion could probably be persuaded
to do it by a few
In this testcase, A is for some reason considered volatile, so the first
write is not removed:
procedure Vol is
A : Integer;
pragma Import (C, A);
begin
A := 1;
A := 2;
end;
$ gcc -S -O2 vol.adb
$ grep mov vol.s
movl%esp, %ebp
movl$1, a
movl$2, a
--- Comment #1 from charlet at gcc dot gnu dot org 2007-05-09 13:37 ---
The code is as intended here, and GCC notion of aliasing is not sufficient
to fullfill Ada needs in this case.
Arno
--
charlet at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from charlet at gcc dot gnu dot org 2007-05-09 13:50 ---
Code generated as expected in more recent versions (e.g. trunk).
note that you should avoid using pragma Inline_Always and use pragma Inline and
-gnatn instead.
Arno
--
charlet at gcc dot gnu dot org changed:
--- Comment #1 from bkoz at gcc dot gnu dot org 2007-05-09 13:55 ---
This is an interesting idea, especially if it could be tied in to a gcc-wide
variable.
-benjamin
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31518
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2007-05-09 14:08
---
Just to clarify a little: it's a (questionable) implementation choice, the
GCC 4 aliasing machinery would now make it possible to get rid of the hack.
--
ebotcazou at gcc dot gnu dot org changed:
$ cat return.c
#include assert.h
int f(int x) {
if(x)
return x;
assert(x);
}
$ gcc -O2 -c -Wall -W return.c
return.c: In function int f(int):
return.c:9: warning: control reaches end of non-void function
The call to assert expands to (glibc 2.4):
(static_castvoid ((x) ?
--- Comment #3 from baldrick at gcc dot gnu dot org 2007-05-09 14:42
---
The code is as intended here, and GCC notion of aliasing is not sufficient
to fullfill Ada needs in this case.
Are you sure? gcc got more sophisticated wrt aliasing in the gcc 4 series.
What exactly does Ada
--- Comment #4 from beliavsky at aol dot com 2007-05-09 15:27 ---
(In reply to comment #2)
I get:
words = 'two three'
On x86-64-gnu/linux with latest 4.3
I wonder if this is one that we recently fixed. Can you try with a more
recent
build?
Using Mingw 20070506, the problem
--- Comment #1 from bangerth at dealii dot org 2007-05-09 16:16 ---
Uh, can you elaborate? We get the warning you want if we have
int d (void) { register int a[2]; return a; }
instead. In your case, i.e. return a,1, we return 1, but we still
need evaluate the expression a. I assume
--- Comment #17 from raf2 at msux dot cjb dot net 2007-05-09 16:27 ---
Compilers may warn about this, but they may not issue an error.
Let's see what has to say the freely available Borland C++ 5.5.1 for Windows.
Yes, it wisely stops people from compiling the attached main.cpp:
Error
--- Comment #5 from bangerth at dealii dot org 2007-05-09 16:34 ---
The code originally given is indeed ambiguous. It boils down to this:
---
namespace boo {
template typename T void work(T n);
template typename T struct R { };
template typename T
void
module str_mod
contains
function copy_str(xx) result(yy)
character (len=*), intent(in) :: xx(:)
character (len=1) :: yy(size(xx))
yy = (/xx/)
end function copy_str
subroutine print_vec(labels)
character (len=*), intent(in) :: labels(:)
print*,labels
end subroutine print_vec
!
function
--- Comment #18 from bangerth at dealii dot org 2007-05-09 16:39 ---
(In reply to comment #17)
Are comitee decisions (right or wrong) more important than consequences for
people? So Borland protects people from undefined behaviours when they can,
and
I wonder, isn't what most
--- Comment #1 from vivekrao4 at yahoo dot com 2007-05-09 16:41 ---
A simpler program exhibiting the same bug:
module str_mod
contains
function ccopy(yy) result(xy)
character (len=*), intent(in) :: yy(:)
character (len=1) :: xy(size(yy))
xy = yy
end function ccopy
end module str_mod
!
This program should print out 1.
Instead, it prints out 1024:
program r3
integer*4 a(1025),b(1025),c(1025),d(2048),e(1022)
do i=1,2048
d(i)=i
end do
open (3,file='a',form='unformatted')
write (3) a,b,c,d,e
rewind 3
read (3) a,b,c,d
--- Comment #19 from chris at bubblescope dot net 2007-05-09 17:05 ---
while I agree we shouldn't produce an error here, personally I'm highly
unconvinced by your argument. If I had some code which if called would always
lead to undefined behaviour, but never called it, I would still
Here is the code (nest.cc) that exhibits the error:
templateclass X
class A
{
public:
class B
{
public:
int i;
};
class C: public B
{
public:
void f()
{
this-i; // OK
i; // results in error: i was not declared in this scope
//
--- Comment #4 from sje at cup dot hp dot com 2007-05-09 17:21 ---
While testing my change (commenting out the checking code at the top of
subst_reload), I found that limits-fnargs.c sped up but I still get timeouts
for limits-fndefn.c.
--
--- Comment #1 from ghood at psc dot edu 2007-05-09 17:22 ---
Created an attachment (id=13534)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13534action=view)
nest.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31881
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-09 17:23 ---
I don't think this is a bug. class B is dependent so the inherited elements are
not seen.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31881
--- Comment #5 from steven at gcc dot gnu dot org 2007-05-09 18:45 ---
The cause of this bug is obvious. We move insns out of the loop either by
emitting the SET_SRC of an insn before the loop, or by reordering the insns
such that the invariant SET is moved into the pre-header. The
--- Comment #3 from ghood at psc dot edu 2007-05-09 19:04 ---
OK, I now understand the issue here. The fact that B and C were not
explicitly templatized, and the other compilers accepted it, led me
to think that it was valid code. In case anyone else is interested,
there's an
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-09 19:18
---
Confirmed on i686-linux, for all active branches.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from sje at cup dot hp dot com 2007-05-09 22:05 ---
It looks like the slowdown in limits-fndefn.c is different than the slowdown
for limits-fnargs.c. The compilation time in limits-fndefn.c is spent in
push_to_sequence. The problem is that each (32 bit) argument is
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-09 22:07 ---
We should get the same warning while compiling with optimizations and while
compiling without so I don't think this is a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31878
--- Comment #2 from lloyd at randombit dot net 2007-05-09 22:16 ---
So are you saying that it is the case that the f() function below might return
without a value? Since that is what the warning suggests.
(My interpretation re the optimizer may be completely off, I don't know GCC
In http://gcc.gnu.org/ml/fortran/2007-03/msg00577.html I have reported a few
typos in the dg directives of the gfortran testsuite and I have proposed a
patch in
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00064.html
Since then I have found some more:
[karma] dominiq/test% grep -r do-run
--- Comment #1 from dominiq at lps dot ens dot fr 2007-05-09 22:24 ---
Created an attachment (id=13535)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13535action=view)
diff for the fixes of the typos, dg-output, and leftovers in
gcc/testsuite/gfortran.dg
--
--- Comment #2 from dominiq at lps dot ens dot fr 2007-05-09 22:31 ---
Created an attachment (id=13536)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13536action=view)
modernize gcc/testsuite/gfortran.fortran-torture/compile/
This diff allows to remove the leftovers due to
--- Comment #3 from dominiq at lps dot ens dot fr 2007-05-09 22:33 ---
Created an attachment (id=13537)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13537action=view)
modernize gcc/testsuite/gfortran.fortran-torture/execute/
This diff allows to remove the leftovers due to
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-09 22:37 ---
After these patches I get:
# of expected passes18091
# of unexpected failures30
# of expected failures 8
# of unsupported tests 58
the failures being large_real_kind_2.F90 and
When libstdc++-v3/testsuite/ext/pb_ds/example/priority_queue_dijkstra.cc
calls p.pop, the highest priority node is deallocated. All but the last
node are still used after being deallocated. In particular, the
node with id zero is deallocated after it has been processed.
Then when processing the
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-09 22:53 ---
gfc_conv_expr_descriptor, at fortran/trans-array.c:4474:
if (expr-ts.type == BT_CHARACTER)
{
if (expr-ts.cl == NULL)
{
/* This had better be a substring reference!
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-09 23:10 ---
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00021.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14513
Look at:
http://gcc.gnu.org/ml/gcc/2004-03/msg00668.html
for a real description of why this is invalid
--- Comment #3 from sje at cup dot hp dot com 2007-05-09 23:12 ---
I tested the patch on IA64 HP-UX and Linux and verified that it fixed the bug
and caused no regressions. Jim, do you want to check this patch in?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31684
--- Comment #2 from neil at daikokuya dot co dot uk 2007-05-09 23:39
---
Subject: Re: Failure to diagnose taking address of register variable
bangerth at dealii dot org wrote:-
Uh, can you elaborate? We get the warning you want if we have
int d (void) { register int a[2]; return
--- Comment #3 from bangerth at math dot tamu dot edu 2007-05-09 23:46
---
Subject: Re: Failure to diagnose taking address of register
variable
for that case, C99's clause 6.3.2.1/3 says that that's possible for
register storage class arrays but that the result is undefined.
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from neil at gcc dot gnu dot org 2007-05-10 00:00 ---
Agreed it's minor; I think I flagged the PR that way.
I'm not sure but I suspect it indicates that the pointer decay is not
happening. If so and you were using GCC to do source code analysis, you would
have an
--- Comment #3 from kkojima at gcc dot gnu dot org 2007-05-10 00:05 ---
__sdivsi3_i4 can't be called via PLT in the first place. This is
a design decision, I think. It is defined as a hidden symbol and
isn't exported from the shared libgcc with the right configuration.
All binaries
Hi, when working on the pointer plus branch I noticed that we fail to remove an
empty finite loop, we would fold array p+ 4 into array[1] and then scev would
get the incorrect result and not optimize it.
Here is a testcase which is producable on the mainline:
struct s {
int *blah;
};
static
--- Comment #3 from truedfx at gentoo dot org 2007-05-10 00:33 ---
I see the same behaviour with gcc 3.3.6. I'm not able to check even older
versions for now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31869
--- Comment #2 from kkojima at gcc dot gnu dot org 2007-05-10 00:45 ---
I've confirmed that the testcase fails with 4.1 and doesn't fail
with 4.0, 4.2 and 4.3. It looks similar to fr30's PR target/21283.
Does the patch below work for you?
--- ORIG/gcc-4_1-branch/gcc/config/sh/sh.md
--- Comment #2 from kargl at gcc dot gnu dot org 2007-05-10 00:47 ---
(In reply to comment #1)
Confirmed on i686-linux, for all active branches.
I'm not sure how you can confirm this. The program is invalid.
a,b,c, and e are undefined in the write statement, so gfortran
can do
--- Comment #3 from roconnor2 at tampabay dot rr dot com 2007-05-10 01:02
---
(In reply to comment #2)
(In reply to comment #1)
Confirmed on i686-linux, for all active branches.
I'm not sure how you can confirm this. The program is invalid.
a,b,c, and e are undefined in the
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-05-10 01:07
---
I am regression testing the patch.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-10 02:01
---
Subject: Bug 31880
Author: jvdelisle
Date: Thu May 10 01:01:27 2007
New Revision: 124588
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124588
Log:
2007-05-09 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-10 02:10
---
Subject: Bug 31880
Author: jvdelisle
Date: Thu May 10 01:09:57 2007
New Revision: 124590
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124590
Log:
2007-05-09 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-10 02:14
---
Russel, thanks for finding this and reporting it. I assume you do not have
copyright assignment. I committed the patch because it is very small and
simple.
Thanks much!
--
--- Comment #4 from rmansfield at qnx dot com 2007-05-10 03:01 ---
Thanks for looking at the PR. Has sdivsi3_i4 has always been hidden? I still
link against some shared libraries built with 2.95.3 where __sdivsi3_i4 is not
hidden. r1-r3 are in the clobber list for 2.95.3 so I don't trip
--- Comment #5 from kkojima at gcc dot gnu dot org 2007-05-10 03:19 ---
Yes. 2.95.3 are broken about this and 2.95.3 libraries are ABI
incompatible with the newer binaries. That will never be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
--- Comment #3 from sugioka at itonet dot co dot jp 2007-05-10 03:25
---
It worked fine. Thanks a lot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31876
--- Comment #5 from bangerth at dealii dot org 2007-05-10 03:52 ---
(In reply to comment #4)
I'm not sure but I suspect it indicates that the pointer decay is not
happening.
Or that the warning is only emitted if something is actually done with the
result. I don't know, someone else
When compiling following code with no optimize flags given, gcc will complain:
1 __attribute__((always_inline)) unsigned int
2 alloc_null_binding1(void)
3 {
4 return 1;
5 }
6
7 static inline __attribute__((always_inline)) int
ip_nat_initialized1(void)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-10 04:19 ---
I don't think this is a bug. The documentation for always inline says:
For functions declared inline, this attribute inlines the function even if no
optimization level was specified.
That quote is from:
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-10 04:22
---
Subject: Bug 31880
Author: jvdelisle
Date: Thu May 10 03:22:40 2007
New Revision: 124591
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124591
Log:
2007-05-09 Jerry DeLisle [EMAIL PROTECTED]
PR
--- Comment #2 from zhouzhouyi at ercist dot iscas dot ac dot cn
2007-05-10 04:41 ---
Subject: Re: (different from bug report c/31077 and 29241) C
handling of always_inline attribute error and a solution
Dear pinskia,
If you lookup my solution current handling of conditions
for
--- Comment #3 from zhouzhouyi at ercist dot iscas dot ac dot cn
2007-05-10 04:43 ---
Subject: Re: (different from bug report c/31077 and 29241) C
handling of always_inline attribute error and a solution
heh, pinkia, take a look at my solution1
On 10 May 2007 03:41:06 -
--- Comment #6 from rmansfield at qnx dot com 2007-05-10 04:55 ---
(In reply to comment #5)
Yes. 2.95.3 are broken about this and 2.95.3 libraries are ABI
incompatible with the newer binaries. That will never be fixed.
Okay, that's fine.
I also wasn't aware of the ABI change.
--- Comment #7 from kkojima at gcc dot gnu dot org 2007-05-10 05:24 ---
From the patch
http://gcc.gnu.org/ml/gcc-patches/2002-02/msg01856.html
which was for 3.2, I think.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26636
--- Comment #4 from zhouyi04 at ios dot cn 2007-05-10 05:33 ---
Dear Pinsky
In addition,
The problem will still exists even add a inline to line 1 of the program,
unless you add a static to line 1.
Sincerely yours
Zhouyi Zhou
--
zhouyi04 at ios dot cn changed:
What
/* With revision 124583, using compiler command ./xgcc -B./ -O -S ~/qual.c
in the prev-gcc directory once it's been updated with the current
binaries, the compiler complains:
qual.c:11: warning: passing argument 1 of 'foo' discards qualifiers from
pointer target type
*/
typedef unsigned
In the source file i'm going to attach, with compiler rev 124583, the generated
assembly code includes a sequence:
jg .L2
jge .L6
.L2:
...
This would be more efficient as a je .L6, and with the alternate (simpler)
implementation of data_eq, that's how it compiles.
--
Summary:
--- Comment #1 from raeburn at raeburn dot org 2007-05-10 05:51 ---
Created an attachment (id=13538)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13538action=view)
source file, with comments on problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31888
The source file I'm submitting has two implementations of an inline function,
and a second function which calls it and then prints one of two strings
depending on the return value. With the simpler implementation of the inline
function, one call to puts() is followed by a jump to the return
--- Comment #1 from raeburn at raeburn dot org 2007-05-10 06:04 ---
Created an attachment (id=13539)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13539action=view)
sample source code, with assembly comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31889
Even though I specified i686-pc-linux-gnu as the platform this should be
applicable to all platforms, if you compile Java.
I'm not an expert on Java - but the file gcc-4_2-branch/libjava/HACKING says:
...
If you add a class to java.lang, java.io, or java.util
(including sub-packages, like
--- Comment #3 from rob1weld at aol dot com 2007-05-10 06:43 ---
I tried an un-modified Makefile on WinXP, running X11 under Cygwin, with Xterm
running bash, compiling with cygwin (whew!) - the problem does NOT occur there.
This problem only seems to occur under a Cygwin MSDOS shell
--- Comment #5 from rob1weld at aol dot com 2007-05-10 06:51 ---
Having great success compiling GCC (with nearly every option enabled) using the
above instructions. More recent compile test results are here:
Results for 4.2.0 20070501 (prerelease) testsuite on i686-pc-cygwin
87 matches
Mail list logo
