This same problem also occurs on i686-pc-cygwin, it likely would occur on all
platforms.
The ./configure scripts "gcc-4_2-branch/libjava/configure" and
"gcc-4_2-branch/libjava/classpath/configure" are out of sync.
During "make" I get this message:
checking for pkg-config... /usr/bin/pkg-config
--- Comment #2 from steven at gcc dot gnu dot org 2007-05-10 07:13 ---
Try compiling with "--param min-crossjump-insns=1". I'm curious to hear if
that fixes this problem for you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31889
--- 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
http://gcc.
--- 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 run
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 ja
--- 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=13539&action=view)
sample source code, with assembly & comments
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31889
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 sequen
--- 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=13538&action=view)
source file, with comments on problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31888
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
/* 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 unsig
--- 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|
--- 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 #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. Wh
--- 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 -
"zhouzhou
--- 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 op
--- 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=gcc&view=rev&rev=124591
Log:
2007-05-09 Jerry DeLisle <[EMAIL PROTECTED]>
--- 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:
http://gc
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 #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
--- 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 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 #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 #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!
--
http://gcc.gnu.org/bugzilla/show_
--- 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=gcc&view=rev&rev=124590
Log:
2007-05-09 Jerry DeLisle <[EMAIL PROTECTED]>
--- 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=gcc&view=rev&rev=124588
Log:
2007-05-09 Jerry DeLisle <[EMAIL PROTECTED]>
--- 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 #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
--- 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 wh
--- 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 #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
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 st
--- 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 and
--- 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 incorre
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- 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.
--- 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]; retur
--- 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 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 code.
--- 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!
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 n
--- 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 l
--- 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=13537&action=view)
modernize gcc/testsuite/gfortran.fortran-torture/execute/
This diff allows to remove the leftovers due to
gcc/te
--- 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=13536&action=view)
modernize gcc/testsuite/gfortran.fortran-torture/compile/
This diff allows to remove the leftovers due to
gcc/te
--- 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=13535&action=view)
diff for the fixes of the typos, dg-output, and leftovers in
gcc/testsuite/gfortran.dg
--
http://gcc.gnu.org
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 gcc/test
--- 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
intern
--- 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 #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 gener
--- 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 #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 explanati
--- 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 cod
--- 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 #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=13534&action=view)
nest.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31881
--- 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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
Here is the code (nest.cc) that exhibits the error:
template
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"
// even
--- 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 wan
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 #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
!
p
--- 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 p
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 ccopy(y
--- 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 void work(T n);
template struct R { };
template
void rfunc(const R& a) {
using boo::work;
--- 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":
Erro
--- 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 #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 probl
--- 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
$ cat return.c
#include
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_cast ((x) ? 0 : (__assert
--- 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:
--- 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 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 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 |Ad
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
T
--- 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 chan
--- 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 #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 #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 #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=13533&action=view)
pre-processed code
Source code which causes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
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 rtlhooks.c:5
--
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
79 matches
Mail list logo
