--- Comment #2 from pault at gcc dot gnu dot org 2007-05-22 09:07 ---
(In reply to comment #1)
> I have been thinking about how best to fix pr30746 and will add this one to my
> reflections.
I fixed 30746 but this PR remains. It is, if anything, a bit more difficult
because there is at
--- Comment #1 from krebbel at gcc dot gnu dot org 2007-05-22 09:16 ---
Fixed by:
http://gcc.gnu.org/viewcvs?view=rev&revision=124938
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-22 09:23
---
There's more to it. When generate wrong-code for optional arguments, as shown
by the following code:
$ cat b.f90
program trs
implicit none
integer :: size, ierr
integer, allocatable, dimension(:) :: seed
I obtained the gcc 4.3 trunk as per the instructions on the web site
(http://gcc.gnu.org/svn.html) using SVN. After all the files arrive and the
checkout is completed it would _seem_ that the file "LAST_UPDATED" is missing.
One (old) changelog says that the file is ".cvsignore" (don't get it) and
--- Comment #19 from charlet at gcc dot gnu dot org 2007-05-22 09:51
---
Just to clarify: the patch posted is only a workaround/kludge, not a
real fix.
Arno
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10768
I'm getting the following ICE at -O3 with 4.3. This was introduced between
0070422 and 20070515.
(sid)24741:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -c -O3
dash-options.i
/home/tbm/src/b/dash-0.5.3/build-tmp/../src/options.c: In function 'setparam':
/home/tbm/src/b/dash-0.5.3/build-tm
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-22 09:53 ---
bootstrap with fold-checking is known to be broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
I'm getting the following ICE at -O3 with 4.3. This was introduced between
0070422 and 20070515.
(sid)24742:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O3
crawl-beam.ii
beam.cc: In function 'void explosion(bolt&, bool)':
beam.cc:4055: internal compiler error: in fold_comparison, at f
On the i686-pc-linux-gnu target libjava compiles clean, except here:
make[4]: Leaving directory
`/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/scripts'
Making all in tools
make[4]: Entering directory
`/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava/classpath/tools'
mkdir -p classes/gnu/class
--- Comment #1 from tbm at cyrius dot com 2007-05-22 10:06 ---
Reduced testcase:
struct shparam
{
char **p;
};
freeparam (volatile struct shparam *param)
{
char **ap;
for (ap = param->p; *ap; ap++)
free ((void *) (param->p));
}
struct shparam shellparam;
setparam (void)
{
fr
ux-gnu
Configured with: /USER/philippe/Irix/Gcc_Sources/configure
--prefix=/usr1/MICRESS/Philippe/Tools/Gcc --enable-languages=c,fortran
--disable-maintainer-mode --disable-shared
--with-mpfr=/usr1/MICRESS/Philippe/Tools/Mpfr
--with-gmp=/usr1/MICRESS/Philippe/Tools/Gmp --with-htmldir
Thread model: pos
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-22 10:27
---
Subject: Bug 31627
Author: fxcoudert
Date: Tue May 22 09:27:15 2007
New Revision: 124940
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124940
Log:
PR fortran/31627
* trans-array.c (gfc_t
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-22 10:28
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from bonzini at gnu dot org 2007-05-22 10:33 ---
Please try this patch on top of the previous one. Its purpose is just to
validate the logic of the previous one, it's not meant to be committed.
Index: libgcc/configure.ac
==
The following testcase is extracted from gfortran.dg/pr19928-2.f90. It shows
that the array index is evaluated multiple times.
$ cat u.f90
type t
integer, dimension (5) :: field
end type t
type (t), dimension (2) :: a
integer :: calls
a(1)%field = 0
a(2)%field = 0
calls = 0
if
--- Comment #105 from rguenth at gcc dot gnu dot org 2007-05-22 10:50
---
Let me again do a step back and look at the problem from another view ;)
--
C++ aliasing imposes additional restrictions on transformations we
are allowed to do to memory references compared to C type-based
alia
--- Comment #1 from tbm at cyrius dot com 2007-05-22 11:11 ---
Reduced testcase:
static int spready[] = {
};
void explosion_map (int y)
{
for (int i = 0; i < 4; i++)
if (y * spready[i] < 0)
break;
}
void explosion (void)
{
explosion_map (0);
for (int i = 0; i < 2; i++)
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-22 11:15 ---
The error message comes from the middle-end and the variable name is Integer_1,
line 33 is:
READ ( 5, * ) Integer_1
There are two problems: First, why has the variable no name for the middle end;
secondly, w
[I submitted this to the mailing list before realizing nobody would notice it.
So, if anyone did, apologies for the duplication!]
So, I've been trying to build gcc with --enable-objc-gc. At first I
thought the failure to build was simply due to random bitrot;
searching the list archives doesn't
The testcase gfortran.dg/pr25603.f is invalid code. The following variables are
not initialized:
lhelpa lhelp lcn lbn lan ldcdy ldcdx lkm ltm lvg lug lvm lum lhvar lzet ldep
lvdep ltstr lustr lobuk ltavr lsteph lhmix lz0 lelevy lelevx lelev ldkzh
ldkzm
lq lpstep lpi lwz lvstep lvy lustep lux
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
c/gcc/i686-pc-linux-gnu/4.3.0
3. Run this executable, with all the arguments, prefixed with "gdb -args".
That will give something like:
gdb -args
/tmpdir/opt/gfortran/gfortran-20070522/bin/../libexec/gcc/i386-pc-linux-gnu/4.3.0/f951
a.for -ffixed-form -quiet -dumpbase a.for -mtune=i
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-05-22 12:40
---
(In reply to comment #3)
> I have Fedora 6 on x86-64. Works OK here. However, we have a leak.
Well, the leak is also triggered by the simple following two lines:
SUBROUTINE XYZ
END
==10212== 1,012
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-05-22 13:01
---
Another testcase (from gfortran.fortran-torture/execute/der_io.f90), probably
the same bug:
$ cat der_io.f90
type xyz_type
integer :: x
end type xyz_type
type (xyz_type), dimension(3) :: xyz
xyz(1
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-05-22 13:06
---
(In reply to comment #7)
> I plan to follow up in stage 1 of 4.3
ping?
There was a patch for %I64 proposed here:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00767.html
--
fxcoudert at gcc dot gnu dot org
The following code should not compile:
struct A
{
int foo(int);
};
struct B : public A
{
int foo(long);
// using A::foo; // This would make it visible
};
struct C : public B
{
using A::foo; // A::foo should not be visible
};
The problem should be that B::foo hides A::foo from class C.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last recon
Hi,
I have successfully built SH4-Linux toolchain based on
(binutils-2.17, gcc-4.2-20061205, glibc-2.5) for Renesas SH target.
I am facing problems while executing the following testcase-
--
TESTCASE
function()
{
#include
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-22 13:26 ---
Confirmed. We enter with the unfolded tree
D.2472_4 * 0 < 0
which is propagated from
D.2473_6 = D.2472_4 * 0
during forwprop. inlining is not properly folding its trees during inlining
of explosion_map (0
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-22 13:29 ---
This works as designed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-22 13:31
---
Tobias, what is the current status on that bug?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-22 13:33 ---
Confirmed. Possibly another missing has_volatile_ops.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #26 from kazssym at nifty dot com 2007-05-22 13:37 ---
(In reply to comment #25)
> This patch (mh-interix.diff) and the previous one (interix-winnt.diff) let me
> successfully "make bootstrap" gcc-4.2-20061212 on Win2K/Interix3.5, without
> manual intervention, with the follo
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-22 13:45 ---
(In reply to comment #6)
> Tobias, what is the current status on that bug?
The attached patch is ok, except it fixes only part of the problem.
I got stuck at:
operator(+) => operator(.op.)
That is: importing an us
--- Comment #20 from eweddington at cso dot atmel dot com 2007-05-22 14:24
---
Subject: RE: ICEs on compilation of ada support library for
avr
> -Original Message-
> From: charlet at gcc dot gnu dot org
> [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 22, 2007 2:51 AM
> T
--- Comment #2 from suma dot sharma at kpitcummins dot com 2007-05-22
14:35 ---
(In reply to comment #1)
> This works as designed.
>
Thank you for your reply.
Please confirm whether it is expected behaviour (that means it is not a bug).
But it was also observed that
1. there is a di
--- Comment #21 from charlet at adacore dot com 2007-05-22 14:26 ---
Subject: Re: ICEs on compilation of ada support library for avr
> Then what would be a real fix that could actually be approved and committed?
Fix support for long (or long long ?) in the avr back-end.
Arno
--
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-22 14:56 ---
(In reply to comment #4)
> Waiting for 4.2 to thaw before a backport.
If you think it should be backported to 4.2 (regression, serious bug), you now
may backport it. Otherwise, you can close this PR.
Mark Mitchell:
GCC seems to have taken the view that compound expressions are permitted as the
2nd argument to offsetof. However the implementor of the grammar forgot that
-> could be used.
#include
struct s
{
struct { float f; } sa[2];
};
enum { e = offsetof (struct s, sa->f) };
--
Summary: of
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-22 15:10 ---
Subject: Bug 31559
Author: burnus
Date: Tue May 22 14:09:42 2007
New Revision: 124943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124943
Log:
fortran/
2007-05-22 Tobias Burnus <[EMAIL PROTECTED]>
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-22 15:14 ---
Fixed in 4.2.1.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-22 15:15 ---
If you think it should be backported to 4.2 (regression, serious bug), you now
may backport it. Otherwise, you can close this PR.
Mark Mitchell: "GCC 4.2 branch open for regression fixes"
http://gcc.gnu.org/ml/gcc-pa
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-22 15:16 ---
If you think it should be backported to 4.2 (regression, serious bug), you now
may backport it. Otherwise, you can close this PR.
Mark Mitchell: "GCC 4.2 branch open for regression fixes"
http://gcc.gnu.org/ml/gcc-pa
--- Comment #5 from burnus at gcc dot gnu dot org 2007-05-22 15:28 ---
Subject: Bug 31915
Author: burnus
Date: Tue May 22 14:27:53 2007
New Revision: 124944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124944
Log:
libgfortran/
2007-05-22 Tobias Burnus <[EMAIL PROTECTED]>
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-22 15:28 ---
Fixed for 4.2.1.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|A
--- Comment #2 from jakub at gcc dot gnu dot org 2007-05-22 15:30 ---
Testing a patch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|una
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-22 15:32 ---
Paul, the 4.2 branch is open again, if you want you could backport this; it
seems to be a regession wrt g77.
Mark Mitchell: "GCC 4.2 branch open for regression fixes"
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg0101
The following code defines the same external function twice, once with C++
linkage, and once with C linkage. GCC 4.1.1 does not complain.
void
foo ()
{
extern int f(int);
}
extern "C" int f(int i); // conflict
However, the following example is properly rejected:
extern int f(int);
extern "C"
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-22 15:59 ---
Confirmed. Same for C++.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
ck 664
/root/downloads/gcc-4_3-trunk/gcc/ada/ali.adb:2265: error: control flow in the
middle of basic block 664
+===GNAT BUG DETECTED==+
| 4.3.0 20070522 (experimental) (i686-pc-linux-gnu) verify_flow_info failed|
| Error detected around /root/down
--- Comment #106 from mark at codesourcery dot com 2007-05-22 16:04 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
rguenth at gcc dot gnu dot org wrote:
> - we _cannot_ sink loads across stores.
>
> x = *int;
> *d
--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-22 16:16 ---
Won't work on it for a while.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Last
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|burnus at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #107 from rguenther at suse dot de 2007-05-22 16:20 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Tue, 22 May 2007, mark at codesourcery dot com wrote:
> rguenth at gcc dot gnu dot org wrote:
>
> > - we _can
--- Comment #10 from daney at gcc dot gnu dot org 2007-05-22 16:21 ---
This bug was triggered on the trunk by:
$ svn log -r 124258
r124258 | hubicka | 2007-04-28 01:20:08 -0700 (Sat, 28 Apr 2007) | 50 lines
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-22 16:31 ---
> why has the variable no name for the middle end;
that is a front issue for now, it might not be complaining about Integer_1 but
a different variable.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 16:32 ---
Use gcc_update to get LAST_UPDATED.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32031
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-05-22 16:46
---
(In reply to comment #6)
> I've reproduced the problem on the official 2007-05-18 snapshot.
Can you reproduce it with the binaries available from the following link?
http://quatramaran.ens.fr/~coudert/gfortran/gf
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
| new does not change the dynamic type as it should
|
| rguenth at gcc dot gnu dot org wrote:
|
| > - we _cannot_ sink loads across stores.
| >
| > x = *int;
| > *double
--- Comment #108 from gdr at cs dot tamu dot edu 2007-05-22 16:55 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
--- Comment #7 from dominiq at lps dot ens dot fr 2007-05-22 16:55 ---
> Please try this patch on top of the previous one.
Sorry, bad news again: I got the same failure (still have -mdynamic-no-pic).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32009
--- Comment #6 from magnus_os at yahoo dot se 2007-05-22 16:38 ---
I've reproduced the problem on the official 2007-05-18 snapshot. This backtrace
is from that:
Program received signal SIGILL, Illegal instruction.
0x086b7d19 in mpfr_ceil_double ()
(gdb) where
#0 0x086b7d19 in mpfr_cei
--- Comment #3 from patchapp at dberlin dot org 2007-05-22 17:05 ---
Subject: Bug number PR31295
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01461.html
--
http://gcc.gnu.org/bugzilla/sh
gcc -O2 -v reord-bb.c
Using built-in specs.
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 --libdir=/usr/lib --libexecdir=/usr/lib
--enable-languages=c,c++,objc,fortran,
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 17:12 ---
No, what GCC is doing is correct, it is ok to duplicate Basic blocks. What you
are doing with the inline-asm is incorrect as you cannot jump into an
inline-asm without many troubles.
--
pinskia at gcc dot gnu d
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-22 17:19 ---
Subject: Bug 31295
Author: burnus
Date: Tue May 22 16:19:09 2007
New Revision: 124948
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124948
Log:
2007-05-22 Tobias Burnus <[EMAIL PROTECTED]>
PR libgf
--- Comment #4 from burnus at gcc dot gnu dot org 2007-05-22 17:19 ---
Subject: Bug 31295
Author: burnus
Date: Tue May 22 16:19:09 2007
New Revision: 124948
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124948
Log:
2007-05-22 Tobias Burnus <[EMAIL PROTECTED]>
PR libgf
--- Comment #109 from mark at codesourcery dot com 2007-05-22 17:19 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> Consider the following instead
>
>// tu-1.C
>void f(int* p) {
>
First I am herewith re-afirming my formal request for Mr. Pinsk to refrain from
having anything to do with my submissions.
Now to the heart of the matter:
According to my (admittedly second hand (Fifth Edition of "C A Reference
Manual"
by Samuel P. Harbison III & Guy L. Stelle Jr) reading; GCC, b
--- Comment #8 from magnus_os at yahoo dot se 2007-05-22 17:22 ---
I downloaded the binaries, and no problems with those.
gfortran -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure
--prefix=/home/fxcoudert/gfortran_ni
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| > Indeed, consider this:
| >
| >// tu-2.C
| >void f(int*);
| >void g() {
| > union {
| > int i;
| > double d;
| > } t;
| >
| > t.i = 42;
| > f(&t);
| > cout << t.d << endl;
| >
--- Comment #110 from gdr at cs dot tamu dot edu 2007-05-22 17:25 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| > Indeed, consider this:
| >
| >// tu-2.C
| >
--- Comment #1 from malitzke at metronets dot com 2007-05-22 17:27 ---
Created an attachment (id=13601)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13601&action=view)
*.s files
I believe that the *.s files in this case a superior to the *.i files
--
http://gcc.gnu.org/bugzi
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-05-22 17:33
---
(In reply to comment #8)
> I use the GMP/MPFR libraries from Fedora 6. No other installation of MPFR has
> been done.
Hum, that's more than probably it: FC6 has a GMP which contained an older
version of MPFR. The
--- Comment #2 from malitzke at metronets dot com 2007-05-22 17:37 ---
Created an attachment (id=13602)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13602&action=view)
*.s files for gcc-4.2
*.s files generated by gcc-4.2.1 as more responsive to the intent and superior
in performa
--- Comment #111 from mark at codesourcery dot com 2007-05-22 17:37 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> | No, I do not. And GCC historically has not; you are only allowed to use
--- Comment #4 from tbm at cyrius dot com 2007-05-22 17:39 ---
Fixed.
--
tbm at cyrius dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #3 from tbm at cyrius dot com 2007-05-22 17:43 ---
Adding Honza to cc: in the hope he can help since he fixed PR30509.
--
tbm at cyrius dot com changed:
What|Removed |Added
---
--- Comment #2 from yakov at emc dot com 2007-05-22 17:44 ---
Subject: Re: Basic block reordering creates two images of bb2,
What do you mean "jump into an inline-asm without many troubles."?
Many troubles during execution or run-time?
Please, look at *.bbro file made by:
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| But, I don't think the standard contemplated
| these issues in sufficient detail to make it useful in this respect.
The issues has been raised on the -core reflector.
-- Gaby
--- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| But, I don't think the stand
--- Comment #113 from mark at codesourcery dot com 2007-05-22 17:54 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> --- Comment #112 from gdr at cs dot tamu dot edu 2007-05-22 17:46
--- Comment #6 from burnus at gcc dot gnu dot org 2007-05-22 17:58 ---
> Created an attachment (id=13364)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13364&action=view) [edit]
This is only standard conform after changing dfloat() to real(..., kind(0d0))
and after changing
call
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
GCC host trip
--- Comment #114 from gdr at cs dot tamu dot edu 2007-05-22 18:01 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"mark at codesourcery dot com" <[EMAIL PROTECTED]> writes:
| Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-22 18:05 ---
Close as works for me as it works with the released gfortran 4.2 and with the
current 4.3 developer version.
You can your Linux vendor for a GCC/gfortran 4.2 (some already have optionally
4.2). Prebuild version can b
--- Comment #15 from aldot at gcc dot gnu dot org 2007-05-22 18:10 ---
(In reply to comment #14)
> Can this be considered fixed?
>
The initial issue is IMO fixed, the other questions raised in this PR are not
dealt with, AFAIK. See comments #8 to #10. Due to these, i did not close the
r
--- Comment #115 from dberlin at gcc dot gnu dot org 2007-05-22 18:10
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 22 May 2007 16:54:24 -, mark at codesourcery dot com
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment
The shell script libjava/classpath/lib/gen-classlist.sh uses "test -e" which is
not supported in a regular Solaris /bin/sh.
Work-around:
- comment out lines 58 and 66 in gen-classlist.sh
- substitute option -e with -f at line 98 in gen-classlist.sh
--
Summary: unknown option -e for
--- Comment #116 from dberlin at gcc dot gnu dot org 2007-05-22 18:13
---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
On 22 May 2007 17:01:40 -, gdr at cs dot tamu dot edu
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #1
--- Comment #2 from nshmyrev at yandex dot ru 2007-05-22 18:16 ---
Ok, I understand it. Gcc dropped support for cast in lvalues. But can the
message be more specific about the problem itself. It's really hard to
understand the reason from the current one.
--
nshmyrev at yandex dot ru
--- Comment #117 from gdr at cs dot tamu dot edu 2007-05-22 18:19 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"dberlin at dberlin dot org" <[EMAIL PROTECTED]> writes:
[...]
| And if you've raised them now, can you please t
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-22 18:27 ---
t.c:9: error: lvalue required as increment operand
I don't see what the problem is, the error message is clear, a lvalue is
required for the increment operand.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #3 from burnus at gcc dot gnu dot org 2007-05-22 18:29 ---
> > why has the variable no name for the middle end;
> that is a front issue for now
Hmm, why did this trick to get rid of PRs not work? ;-)
Reduced test case:
subroutine Test
implicit none
intege
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-22 18:32 ---
It might have to do with stop not being marked as noreturn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035
--- Comment #4 from nshmyrev at yandex dot ru 2007-05-22 18:33 ---
gcc can explain why ((void **)a) is not lvalue, it's really not that clear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32023
--- Comment #118 from mark at codesourcery dot com 2007-05-22 18:34 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
gdr at cs dot tamu dot edu wrote:
> Thanks for reminding all those points. I'll ensure that I make those
> po
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-22 18:36 ---
You did not follow the instructions on installation
(http://gcc.gnu.org/install/):
The Solaris 2 /bin/sh will often fail to configure libstdc++-v3, boehm-gc or
libjava. We therefore recommend using the following ini
1 - 100 of 198 matches
Mail list logo
