[Since this gcc problem affects gdb, I'm sending this to both lists]
[Warning, long mail. But the actual description isn't that long, just the
testcases are.]
Hi,
a specific test in the GDB testsuite (namespace.exp) contains tests
on variables within anonymous namespaces. When compiling the
Is there a PR existing for multilib build failures
of the form...
configure: error: `CXX' has changed since the previous run
...as described (and patch proposed) in...
http://sourceware.org/ml/newlib/2007/msg00425.html?
I am currently testing that patch with gcc trunk to see if
it
On 25 May 2007 13:03, Jack Howarth wrote:
Is there a PR existing for multilib build failures
of the form...
configure: error: `CXX' has changed since the previous run
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=
On Fri, May 25, 2007 at 02:00:35PM +0200, Corinna Vinschen wrote:
IMHO, this is a bug in g++. The mangled name in DW_AT_MIPS_linkage_name
is required so that GDB can correctly recognize mangled c++ symbols.
Yes, I think so. Keep in mind that, in turn, the dependency on
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote:
We need a configure time option to link statically against GMP and
MPFR even if dynamic versions of the libraries are available.
I would argue that static linking should be the default, since that is
the least surprising
[EMAIL PROTECTED] wrote:
If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
libmpfr.so. If you then copy the compiler to some other system, or
simply
On 5/25/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote:
We need a configure time option to link statically against GMP and
MPFR even if dynamic versions of the libraries are available.
I would argue that static linking should
On 25 May 2007 15:10, Ian Lance Taylor wrote:
I would argue that static linking should be the default, since that is
the least surprising option. People who understand the issues can
enable dynamic linking.
And besides, wasn't it the case that one of the main points in defence of
adding
I just noticed a problem with our use of GMP and MPFR. If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
libmpfr.so. If you then copy the compiler to
It's no different than any other library used by any other program.
I wouldn't object to configure support to request static gmp/mpfr for
developer convenience, but GCC is a perfectly normal dynamically
linked program and should behave like one IMO.
How a compiler can be a perfectly normal
On Fri, May 25, 2007 at 04:33:56PM +0200, Eric Botcazou wrote:
It's no different than any other library used by any other program.
I wouldn't object to configure support to request static gmp/mpfr for
developer convenience, but GCC is a perfectly normal dynamically
linked program and
On 25 May 2007 15:34, Eric Botcazou wrote:
It's no different than any other library used by any other program.
I wouldn't object to configure support to request static gmp/mpfr for
developer convenience, but GCC is a perfectly normal dynamically
linked program and should behave like one IMO.
Tim Prince [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc. wind up dynamically linked against libgmp.so and
libmpfr.so. If you then
On Fri, May 25, 2007 at 07:10:23AM -0700, Ian Lance Taylor wrote:
I just noticed a problem with our use of GMP and MPFR. If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc. wind up dynamically
Dave Korn wrote:
On 25 May 2007 15:34, Eric Botcazou wrote:
It's no different than any other library used by any other program.
I wouldn't object to configure support to request static gmp/mpfr for
developer convenience, but GCC is a perfectly normal dynamically
linked program and should behave
But I don't think that's enough, with the current loop it would strip the
subreg of a multiword subreg and there is some logic in df_ref_record,
which wouldn't see it. An alternative might be:
while (GET_CODE (dst) == STRICT_LOW_PART
|| GET_CODE (dst) == ZERO_EXTRACT)
{
On 25 May 2007 07:52:12 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Tim Prince [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
If you
carefully install the appropriate versions of GMP and MPFR on one
machine in the normal way, and build gcc on that machine,
cc1/cc1plus/etc.
On Fri, May 25, 2007 at 05:37:49PM +0200, Eric Botcazou wrote:
I honestly don't know how to answer this question. Bootstrapping is an
unrelated problem, and the compiler is not a vital runtime component
of the system, so its dependencies do not need to be exceptionally
robust in the way
I honestly don't know how to answer this question. Bootstrapping is an
unrelated problem, and the compiler is not a vital runtime component
of the system, so its dependencies do not need to be exceptionally
robust in the way that glibc's or even libstdc++'s do.
A compiler is a second order
Bootstrapping GCC on a system is something that would be solved by
placing GMP and MPFR in the build tree (as has been proposed), and once
they are built as part of the usual bootstrap, it is irrelevant whether
they are linked statically or dynamically. On the other hand, when one
is
On Fri, 25 May 2007, Daniel Jacobowitz wrote:
On Fri, May 25, 2007 at 05:37:49PM +0200, Eric Botcazou wrote:
I honestly don't know how to answer this question. Bootstrapping is an
unrelated problem, and the compiler is not a vital runtime component
of the system, so its dependencies do
On Fri, 25 May 2007, Dave Korn wrote:
On 25 May 2007 15:34, Eric Botcazou wrote:
Yes, hasn't this been one of the design goals of gcc for as long as any of
us can remember? It wants to be able to bootstrap the GNU world on non-free
systems from scratch and part of that is not requiring
Hi,
about two weeks ago I started submitting patches for C++ compatibility.
Unfortunately reviewing as been, ahem, a bit slow. Probably because
nobody cares about C++ compatibility. As I have only send 4% of the
total patch so far, the current acceptance rate (as in 0 patches in 2
weeks) bothers
Back in 2006 I added a mechanism for defining machine-specific
constraints in the MD file rather than with C macros. This mechanism
offers several advantages over the old way of doing it, but until all
ports are converted, we can't actually implement some of those -- most
important, perhaps, is
On 25/05/07, Thomas Neumann [EMAIL PROTECTED] wrote:
Hi,
about two weeks ago I started submitting patches for C++ compatibility.
Unfortunately reviewing as been, ahem, a bit slow. Probably because
nobody cares about C++ compatibility. As I have only send 4% of the
total patch so far, the
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
?
IMHO, these bugs are especially nasty and should get high visibility
(and maybe even special privileges for fixing on a release branch).
Thomas
Thomas Koenig wrote:
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
IMHO, these bugs are especially nasty and should get high visibility
(and maybe even special privileges for fixing on a release branch).
Well I
On 5/25/07, Thomas Koenig [EMAIL PROTECTED] wrote:
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
?
IMHO, these bugs are especially nasty and should get high visibility
(and maybe even special privileges for
That just means that it's an application you care about. And now an
upgrade of MPFR which fixes bugs will require you to rebuild the
compiler.
Exactly. By design. What goes in the system compiler should be closely
scrutinized.
--
Eric Botcazou
Richard Guenther wrote:
On 5/25/07, Thomas Koenig [EMAIL PROTECTED] wrote:
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
?
IMHO, these bugs are especially nasty and should get high visibility
(and maybe even
I don't personally have time to convert all ports, and it is better if
people who know each individual backend and have access to hardware
do the conversions, anyway. So I'd like to invite port maintainers to
convert their ports in this development cycle. I see that many of
the more
On Friday 25 May 2007, Thomas Koenig wrote:
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
We already have one: wrong-code
1 and 3 mutually exclusive. ie. if we generate an error, then by definition we
don't
Paul Brook wrote:
2 is a IMHO fairly academic distinction. We either care about code working
(and support no-conforming code as an extension), or we decide that we're ok
with that particular code being broken.
That's a better way to express the concern I had. I would not get
excited about
On Fri, 2007-05-25 at 22:12 +0100, Paul Brook wrote:
On Friday 25 May 2007, Thomas Koenig wrote:
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
We already have one: wrong-code
1 and 3 mutually
On Fri, May 25, 2007 at 02:04:16PM -0700, David Daney wrote:
Richard Guenther wrote:
On 5/25/07, Thomas Koenig [EMAIL PROTECTED] wrote:
What about a keyword for bugs that
- generate wrong code
- affect a standard-conforming program
- are silent (no error message)
?
IMHO, these bugs
Hi,
as of revision 125076, tree-vect-transform.c contains the following code
in line 2010:
enum tree_code code, code1 = CODE_FOR_nothing, code2 = CODE_FOR_nothing;
This most likely wrong, CODE_FOR_nothing is an insn_code, not a
tree_code. Unfortunately there is no obvious fix (at least not
Snapshot gcc-4.3-20070525 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070525/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Now!!
You can upload up to 500 MB !
Key features of fileWind.net:
- Free and no need to register to use.
- Easy to use, upload file, receive link, share.
- Files up to 500MB can be uploaded, can split files if too large.
- Unlimited storage, upload as many files as you want.
- Unlimited
[EMAIL PROTECTED] wrote:
However there are two existing options in the mean time:
One is build/install gmp/mpfr yourself and specify --disable-shared to
both. Then use --with-mpfr= to specify using them instead of the system's
shared versions.
The second is to drop gmp/mpfr into the top
On May 25, 2007, at 2:10 PM, Eric Botcazou wrote:
I don't personally have time to convert all ports, and it is
better if
people who know each individual backend and have access to hardware
do the conversions, anyway. So I'd like to invite port
maintainers to
convert their ports in this
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-25 07:17 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pault at gcc dot gnu dot org 2007-05-25 07:34 ---
Subject: Bug 32047
Author: pault
Date: Fri May 25 06:34:10 2007
New Revision: 125057
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125057
Log:
2007-05-25 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-25 07:35 ---
Resolved on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-25 07:35 ---
You know the testresults are not looked at by almost nobody (I am one of the
few person who looks at them).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32063
--- Comment #13 from daney at gcc dot gnu dot org 2007-05-25 08:16 ---
Created an attachment (id=13610)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13610action=view)
Proposed patch.
I will bootstrap and test the attached patch. It allows my cross build to
complete.
--
daney
--- Comment #14 from pinskia at gcc dot gnu dot org 2007-05-25 08:32
---
RS6000, ia64, and sh does this:
/* Mark the end of the (empty) prologue. */
emit_note (NOTE_INSN_PROLOGUE_END);
You might want to use that note also for MIPS.
--
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-25 09:31 ---
Works for me since today.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
compiler error: Segmentation fault
This is with http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html
This is on x86_64-unknown-linux-gnu with gcc-Version 4.3.0 20070525.
Working with: 2007-05-17
Failing since: 2007-05-18
--
Summary: [Regression 4.3] Profile-use: ICE
Two problems - the second one is months old and affects 4.2.0 4.2.1 4.3.0
1) Make breaks due to configure: error: `CXXFLAGS' has changed since the
previous run:
This did not happen yesterday, or the day before, ...
2) When make breaks (for _any_ reason, including the prior one) while
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-25 09:53 ---
Zdenek, I think your patch caused the ICE, could you have a look?
http://gcc.gnu.org/ml/gcc-cvs/2007-05/msg00485.html
(Maybe I'm wrong about the patch, there were some other issues around that
time, which caused
--- Comment #3 from rob1weld at aol dot com 2007-05-25 09:55 ---
Ran accros this interesting post, seems we've had this a while ...
gjdoc in libgcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19612
After some messing with trying to access the gjdoc SVN according to the above
advice
It should not be possible to jump into a function try-block.
The example from the standard, clause 15/2, is rejected properly:
void f() {
goto l1; // Ill-formed
goto l2; // Ill-formed
try {
goto l1;// OK
goto l2;// Ill-formed
l1: ;
} catch (...) {
l2: ;
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-25 10:36 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
The following C++ code should not compile:
template class T
void foo(T) throw (int);
template
void
foo (short) throw (short)
{
}
The change in exception specification, the throw, is not been detected. A
simple example without templates is rejected correctly.
The C++ standard discusses this in
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-25 10:39 ---
This is undefined. You dereference *pp before checking if it is a NULL
pointer.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-25 10:07 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-25 10:07 ---
Fixed.
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-05-25 10:07 ---
Subject: Bug 31982
Author: rguenth
Date: Fri May 25 09:07:29 2007
New Revision: 125058
URL:
below c code will get false at -O0, -O1, -O3,
and get true at -O2, -Os.
#include stdio.h
typedef struct {
int aa;
int bb;
} test;
//test t1;
void foo (test **pp)
{
if (((*pp)-bb != 0) (*pp))
printf (true\n);
else
printf (false\n);
printf (finished.\n);
--- Comment #27 from markus dot duft at salomon dot at 2007-05-25 10:30
---
(In reply to comment #25)
Created an attachment (id=12808)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12808action=view) [edit]
patch (part 2 of 2) to fix this bug
This patch (mh-interix.diff) and the
--- Comment #1 from rob1weld at aol dot com 2007-05-25 10:49 ---
Found an additional problem.
After all the stages are done and we are building the libraries in the target
name directory (EG: in _my_ case the directory is called i686-pc-linux-gnu)
we must _always_ use xgcc and NOT gcc
--- Comment #4 from deknuydt at esat dot kuleuven dot be 2007-05-25 11:12
---
(In reply to comment #3)
Unless you need 4.1 and plan to work on this bug, I would like to close it.
What do you think?
Just close it. 4.2.0 seems okay to me.
--
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure
--prefix=/home/fxcoudert/gfortran_nightbuild/irun-20070525
--enable-languages=c,fortran --build=i386-pc-linux-gnu
--enable-checking=release
--with-gmp=/home/fxcoudert
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-05-25 11:21 ---
Indeed with -fno-tree-ccp the testcase is optimized by forwprop1 to
bb 2:
D.2000_3 = i_2(D) * 4;
D.2001_4 = (int *) D.2000_3;
D.2002_5 = b.t[i_2(D)];
*D.2002_5 = 1;
return;
and then by forwprop2 to
bb
--- Comment #1 from andrew dot stubbs at st dot com 2007-05-25 11:21
---
This problem may also be observed in explicit instantiation:
template class T
void
foo (T) throw (int)
{
}
template
void foo (short) throw (short);
There are also similar issues with declarations of pointers
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-05-25 11:45 ---
Shortened testcase to compare variable vs. parameter in tree dump:
$ cat pr32083.f90
PROGRAM TestInfinite
integer(8), parameter :: bit_pattern_NegInf_i8_p = -4503599627370496_8
integer(8) ::
--- Comment #13 from bero at arklinux dot org 2007-05-25 12:24 ---
yes, assignment is in place, and yes, the peers are somewhat buggy. But I think
that's in part because nobody (at least in the gcj community) is testing/fixing
them because they don't build without trickery.
--
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-25 12:37 ---
This is a regression with regard to 4.2.0.
Brooks, you were looking for transfer regressions, weren't you?
(Just for completeness, 2007-05-15 r124736 is working, 2007-05-16 r124759 is
failing.)
--
burnus at gcc
--- Comment #2 from jakub at gcc dot gnu dot org 2007-05-25 12:39 ---
I'm not sure we want to work around here though. Static const variable
initialized during __static_initialization_and_destruction shouldn't have
TREE_READONLY set, because the variable isn't really unchanging.
This
--- Comment #27 from paul_m_doc at hotmail dot com 2007-05-25 13:11 ---
(In reply to comment #26)
*** Bug 32058 has been marked as a duplicate of this bug. ***
Sigh :(. The response at the October 2006 to DR 577 is enough to make any
template meta-programmer bang their head against
--- Comment #2 from hjl at lucon dot org 2007-05-25 13:31 ---
I saw it with revision 125032 on a quad-core Linux/x86-64 with make -j4.
--
hjl at lucon dot org changed:
What|Removed |Added
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-05-25 13:55
---
Rev. 124497 of mainline fails to bootstrap with these patches on i686-linux:
[during stage2]
../../../trunk3/gcc/df-scan.c: In function df_ref_record:
../../../trunk3/gcc/df-scan.c:1057: error: types mismatch
--- Comment #15 from richard at codesourcery dot com 2007-05-25 14:13
---
Subject: Re: [4.3 Regression] segfault in try_split on mips during bootstrap
David, msny thanks for looking at this.
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
RS6000, ia64, and sh does this:
gfortran seemingly generates an significatly inferior internal TREE
representation than g95 as for Polyhedron's induct.f90 gfortran is 18% slower
than g95, which is based on GCC 4.0.3. (Compared with other compilers the
difference is even larger.)
(GCC 4.3 is in general faster than GCC 4.1; for
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-25 14:25 ---
Created an attachment (id=13611)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13611action=view)
test case, 395 lines; based on Polyhedron's induct.f90
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32084
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:16 ---
Subject: Bug 31444
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 14:16 ---
Subject: Bug 31445
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31442
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31434
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31432
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31431
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #2 from manu at gcc dot gnu dot org 2007-05-25 14:05 ---
(In reply to comment #0)
While this is trivial we should have pride in our great compiler and the
usually great results. Even if there are failures we should still present them
neatly.
If it is trivial, then just
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31437
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31438
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31435
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #1 from dgregor at gcc dot gnu dot org 2007-05-25 14:15 ---
Subject: Bug 31443
Author: dgregor
Date: Fri May 25 13:15:04 2007
New Revision: 125062
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125062
Log:
2007-05-25 Douglas Gregor [EMAIL PROTECTED]
PR
void
operator delete(void *p)
{
}
void
foo ()
{
void *p = new int;
delete p;
}
t.cxx: In function int main():
t.cxx:13: warning: deleting void* is undefined
Oh yes it - I just defined it!
It might be nice if the compiler checked before warning :)
--
Summary: warning:
--- Comment #2 from ubizjak at gmail dot com 2007-05-25 14:53 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01716.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-05-25 14:54 ---
Using the GCC 4.1.3 20070430 which comes with openSUSE Factory and contains
some patches from 4.2/4.3, I get the following timings:
$ gfortran-4.1 -march=opteron -ffast-math -funroll-loops -ftree-vectorize
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-25 15:17 ---
Do either of you read the list?
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01665.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-25 15:37 ---
No, even then it is still undefined because you don't call the deconstructor
for non-PODs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32085
--- Comment #4 from rob1weld at aol dot com 2007-05-25 15:39 ---
Andrew Pinski 2007-05-25 15:17
Do either of you read the list?
I search the Internet and use the search page at http://gcc.gnu.org/bugzilla
before I post a bug. I try to avoid dupes and look for fixes.
There may well
--- Comment #5 from nathan at gcc dot gnu dot org 2007-05-25 15:40 ---
This looks like it might be the same as this one
http://sourceware.org/ml/newlib/2007/msg00425.html
Anyone able to try that patch?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32078
--- Comment #6 from rob1weld at aol dot com 2007-05-25 15:59 ---
After winding up and down, back and forth through what seems to be a couple of
forks of discussion, I found a couple of different answers ...
The above comment means that the References: section at the bottom of the
posts
--- Comment #2 from andrew dot stubbs at st dot com 2007-05-25 16:16
---
I'm confused.
It might be the case that there is a type for which this warning is valid - I
don't know C++ well enough to confirm or deny that - but in *this* example, and
perhaps others like it, the warning is
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-25 16:51 ---
First the operator delete you created is overriding the normal operator delete
(which is valid).
Second you don't know the real type when deleting void* so it is hard to figure
out if we should warn or not.
--
--- Comment #5 from pcarlini at suse dot de 2007-05-25 17:12 ---
(In reply to comment #2)
I don't think support for C++0x precludes support for TR1. They coexist very
well, especially because TR1 was designed to be compatible with C++0x. For
example, C++0x-conforming implementations
The program induct.f90 of the Polyhedron testsuite,
http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html, runs about
10% slower under 4.3 than under 4.1.3 (20070430 prerelease SUSE Linux).
A cut-down testcase test2.f90 (attachment 13611 of PR 32084) shows the same
result. At least for
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-25 17:43
---
Closing. Added the following comment to transfer.c:
/* Master function for unformatted writes. NOTE: For kind=10 the size is 16
bytes on 64 bit machines. The unused bytes are not initialized and never
--- Comment #3 from dgregor at gcc dot gnu dot org 2007-05-25 17:53 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-05-25 17:53 ---
Fixed on mainline.
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 164 matches
Mail list logo
