C:\...gcc -v
Using built-in specs.
Target: djgpp
Configured with: /v203/gcc-4.32/configure msdosdjgpp
Thread model: single
gcc version 4.3.2 (GCC)
Build command line: gpp -oexcpt -DTESTBADE excpt.C
Execute command line: excpt
The following source code is a pared down version of a short
--- Comment #5 from ubizjak at gmail dot com 2009-08-26 06:27 ---
FYI, this testcase also fails on alpha:
FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test
(I was not able to debug it properly, will wait for your reduced testcase...)
--
--- Comment #2 from dodji at gcc dot gnu dot org 2009-08-26 06:41 ---
Patch submitted to http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01405.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41170
--- Comment #2 from gerolf dot wendland at nsn dot com 2009-08-26 06:55
---
(In reply to comment #1)
That would require that the ABI specifies such a mangling. I'm not sure
anyone wants to go that route.
This is exactly what I had in mind. Slightly extended names for
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-08-26 08:45 ---
This looks like a target issue as that message is from rs6000.c.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pault at gcc dot gnu dot org 2009-08-26 09:50 ---
Janus,
Thanks for reporting this. In fact, the bug is worse than you report; the
namespace of 'F1' is never freed!
ns-refs is set to one by gfc_get_namespace
it is incremented in decl.c(get_proc_name):800 for
--- Comment #47 from dominiq at lps dot ens dot fr 2009-08-26 10:32 ---
Created an attachment (id=18427)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18427action=view)
Self contained reduced test for pr40440
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
--- Comment #48 from dominiq at lps dot ens dot fr 2009-08-26 10:34 ---
are there issues other than the ones reported in comment #44
I have opened pr41056 and pr41059 for other problems. There are ICEs for the
original test in pr40440 (with external iso_varying_string.mod, but not if
--- Comment #49 from dominiq at lps dot ens dot fr 2009-08-26 10:35 ---
Finally the last time -fwhole-file was the default, -fno-whole-file, it was
not working.
Please read: Finally the last time -fwhole-file was the default,
-fno-whole-file was not working.
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-08-26 10:54 ---
The issue here is that during linking we do not optimize which triggers the
path in out-of-ssa coalescing that assumes no overlapping life-ranges are
present. Which is obviously not true if we optimized during lto
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-08-26 13:23 ---
Subject: Bug 41163
Author: rguenth
Date: Wed Aug 26 13:23:04 2009
New Revision: 151122
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151122
Log:
2009-08-26 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-08-26 13:37
---
Confirmed.
Shorter testcase (crashes with -O -m32 on x86_64-unknown-linux-gnu):
==
int foo(volatile int i)
{
return (1LL 128 * i) i;
}
==
The
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-08-26 14:05 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Using -Os with gcc4.4 vs gcc4.3 we see a ~15% increase in code size. This is
due to the fact that load/store multiple instructions are not being used for
function prologue/epilogues. The other option would be to use out of line
save/restore calls in the prologue/epilogues (which are also not
--- Comment #1 from galak at kernel dot crashing dot org 2009-08-26 14:18
---
Created an attachment (id=18428)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18428action=view)
size of all object files using gcc 4.3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41175
--- Comment #2 from galak at kernel dot crashing dot org 2009-08-26 14:18
---
Created an attachment (id=18429)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18429action=view)
size of all object files using gcc 4.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41175
--- Comment #3 from galak at kernel dot crashing dot org 2009-08-26 14:20
---
I've attached comparisions of building the same u-boot source tree with gcc-4.3
from Fedora 10 on a PPC 64 host:
[ga...@blarg u-boot-85xx]$ gcc -v
Using built-in specs.
Target: ppc64-redhat-linux
Configured
--- Comment #7 from tromey at gcc dot gnu dot org 2009-08-26 14:28 ---
Typedefs are found using lookup_name.
There is not really a separate mapping; instead the
trees are held directly in the identifier node.
These are reset as typedefs (or whatever) go out of scope,
though.
--
--- Comment #11 from spop at gcc dot gnu dot org 2009-08-26 14:42 ---
This is a fix for this particular bug: I am considering this bug closed, and I
will close it when the patch will be in trunk.
This fix also decreases the compile time of graphite in general. I will send a
pointer
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-26 14:43 ---
IIUC, the top-level const qualifier on const typename FooD::double3 in the
primary template applies to the type, which is not known during phase 1
At instantiation time, double3 is known to be an array type, so decays
--- Comment #2 from bergner at gcc dot gnu dot org 2009-08-26 13:44 ---
The problem here, is that for some reason, IRA is spilling the two pseudos in
the test case, even though it seems it should be trivial. Looking deeper.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
--- Comment #7 from galak at kernel dot crashing dot org 2009-08-26 13:54
---
I'm not what the means are bump the priority on this as a significant
regression in gcc4.4 as code that was building with gcc4.3 no longer builds
because the size of the generated binaries is significantly
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-26 14:51 ---
(In reply to comment #2)
IIUC, the top-level const qualifier on const typename FooD::double3 in the
primary template applies to the type, which is not known during phase 1
i.e. it's equivalent to typename
--- Comment #3 from bergner at gcc dot gnu dot org 2009-08-26 15:14 ---
Actually, they're already reordered by the time we call ira_color and the ira
dumps shows that:
;; Function f (f)
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
--- Comment #4 from bergner at gcc dot gnu dot org 2009-08-26 15:22 ---
It's update_equiv_regs() that is causing this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
--- Comment #1 from redi at gcc dot gnu dot org 2009-08-26 15:31 ---
Reduced:
#include cassert
#include exception
struct GoodE {
GoodE()
{
try {
throw 1;
} catch (...) {
}
}
};
struct BadE {
BadE()
try {
throw 1;
--- Comment #8 from froydnj at gcc dot gnu dot org 2009-08-26 15:50 ---
Even if the problems in expand are fixed, reassoc is still going to cause
problems with the original testcase. From the dse1 dump:
D.2474_14 = (long long int) vLo_11;
D.2475_15 = (long long int) c1_6;
--- Comment #2 from redi at gcc dot gnu dot org 2009-08-26 15:52 ---
It looks as though uncaught_exception() does not always become false when
entering the handler of a function-try-block, and this causes it to stay true.
Maybe the count of uncaught exceptions is not decremented in the
--- Comment #3 from redi at gcc dot gnu dot org 2009-08-26 16:01 ---
(In reply to comment #2)
at the end of the handler, causing it to be one more than it should not be.
Oops, obviously I meant one more than it should be
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
--- Comment #4 from redi at gcc dot gnu dot org 2009-08-26 16:17 ---
(In reply to comment #1)
Note that GoodE doesn't cause the problem. The difference is that BadE has a
function-try-block
And, of course, that the exception is rethrown by BadE at the end of the
handler. Changing
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2009-08-26
16:47 ---
The output from typing gfortran -v is listed below. It is a
cross-compilation, if that is significant.
Built by Equation Solution http://www.Equation.com.
Using built-in specs.
Target: i386-pc-mingw32
--- Comment #5 from redi at gcc dot gnu dot org 2009-08-26 16:50 ---
I think the problem is that the uncaught_exception() is true as soon as the
memory for the exception has been allocated, but if the exception's copy
constructor is elided then happens before entering the exception's
--- Comment #3 from ro at gcc dot gnu dot org 2009-08-26 17:44 ---
Josef, there are a couple of issues with complex support on Solaris 2/IRIX 6
where
you might be able to help.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2009-08-26
17:51 ---
Subject: Re: [4.5 regression] libgfortran fails to build on Solaris 10+:
'_Imaginary_I' undeclared
--- Comment #2 from dje at gcc dot gnu dot org 2009-08-25 21:32 ---
Just follow the style that
--- Comment #4 from peter_foelsche at agilent dot com 2009-08-26 18:06
---
Created an attachment (id=18430)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18430action=view)
gpperror.cpp
shorter testcase
--
peter_foelsche at agilent dot com changed:
What|Removed
--- Comment #5 from peter_foelsche at agilent dot com 2009-08-26 18:13
---
seems to be fixed in gcc v4.4.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40561
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-08-26 18:35 ---
Note that even for
(long long)i * (long long)j * (long long)i
we can only use one mulsidi3, so promoting parts of the multiplications to
additions should be still beneficial.
I suppose we should detect widening
--- Comment #6 from bangerth at gmail dot com 2009-08-26 18:49 ---
It's also fixed on mainline and it works on 4.2.1. I don't have a version of
4.3 lying around, but that would be the only open branch which appears to
still have the problem.
Would someone mind testing this on a current
--- Comment #10 from redi at gcc dot gnu dot org 2009-08-26 19:04 ---
Subject: Bug 41005
Author: redi
Date: Wed Aug 26 19:04:11 2009
New Revision: 151127
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151127
Log:
2009-08-26 Jonathan Wakely jwakely@gmail.com
PR
--- Comment #4 from doriankrause at web dot de 2009-08-26 19:26 ---
Thanks Jonathan for your explanation. Now I can understand the reason behind
this... (though I'm not really happy with the fact that you need to understand
sort of internals to see why code doesn't compile).
Do I need
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-26 19:40 ---
fails with 4.3.4, I don't have a 4.3 branch to check the tip
pr.cc: In constructor VamsSystemFunction__GET_DEP__::VamsSystemFunction()
[with std::setSyAccess*, std::lessSyAccess*, std::allocatorSyAccess*
--- Comment #11 from redi at gcc dot gnu dot org 2009-08-26 19:15 ---
Fixed for 4.4.2 and 4.5.0
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from bangerth at gmail dot com 2009-08-26 19:43 ---
(In reply to comment #7)
pr.cc:38: error: invalid operands of types #8216;bool#8217; and
#8216;int#8217; to binary
#8216;operator==#8217;
This is doubly fascinating as there is no operator== in this line ;-)
W.
The following is the code of vectorized sin computation which uses
a lookup table.
#define NUM_SAMPLES_IN_CIRCLE2 150*1024
extern const int sign_;
extern const int notsign_;
extern __vector float ONE_DIV_PI2_;
extern __vector float numSamples;
extern __vector float sign;
extern __vector float
--- Comment #5 from ami_stuff at o2 dot pl 2009-08-26 20:25 ---
-m68060 -O3 ...:
GCC 4.1.2 - 385KB
GCC 4.2.5 - 386KB
GCC 4.3.2 - 777KB
GCC 4.4.1 - 1,18MB
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41095
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-08-26 20:54 ---
Likely the same issue as PR40992.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hjl at gcc dot gnu dot org 2009-08-26 20:55 ---
Subject: Bug 41162
Author: hjl
Date: Wed Aug 26 20:55:42 2009
New Revision: 151130
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=151130
Log:
2009-08-26 H.J. Lu hongjiu...@intel.com
PR fortran/41162
--- Comment #9 from hjl dot tools at gmail dot com 2009-08-26 20:56 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|REOPENED
--- Comment #5 from bergner at gcc dot gnu dot org 2009-08-26 20:57 ---
From my bug analysis and request for comment on the mailinglist:
http://gcc.gnu.org/ml/gcc/2009-08/msg00485.html
This is caused by update_equiv_regs() which IRA inherited from local-alloc.c.
Although with gcc
--- Comment #3 from jv244 at cam dot ac dot uk 2009-08-26 21:00 ---
I've maybe some insight why this is happening, compiling just the module. By
putting a breakpoint on gfc_set_backend_locus, the break is on
#0 gfc_set_backend_locus (loc=0x12f28b0) at
--- Comment #5 from rwild at gcc dot gnu dot org 2009-08-26 21:39 ---
patch at http://gcc.gnu.org/ml/gcc-patches/2009-08/msg01371.html
avoiding the regression but not fixing issues in remark #2
--
rwild at gcc dot gnu dot org changed:
What|Removed
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--- Comment #12 from paolo dot carlini at oracle dot com 2009-08-26 22:55
---
Thanks Jon. I would say I'm guilty of this issue. To be fully honest, when Ed
proposed these bits of C++0x, I wasn't particularly excited: ok, can be
actually handy but really, we don't expect surprises
--- Comment #4 from sje at cup dot hp dot com 2009-08-26 22:58 ---
In addition to copying the t-* files over, you also need to modify config.gcc.
If you look at the 'alpha*-*-freebsd*' entry in that file you will see where
tmake_file is set to a list of files including t-crtfm. The
--- Comment #6 from hp at gcc dot gnu dot org 2009-08-26 23:09 ---
I see the patch for this PR has been reverted. Please also remove the
test-case, or xfail it until a fix is committed, as it's now technically a
regression (at least my autotester thinks so). Don't forget that you must
--- Comment #15 from sje at cup dot hp dot com 2009-08-26 23:10 ---
Test no longer fails due to checkin that fixes the scan for IA64.
See http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01600.html
--
sje at cup dot hp dot com changed:
What|Removed
with this compiler:
[luc...@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ../../mainline/configure --prefix=/pkgs/gcc-mainline
--enable-languages=c,c++ --enable-stage1-languages=c,c++ --with-cpu=default64
Thread model:
--- Comment #1 from lucier at math dot purdue dot edu 2009-08-27 00:14
---
Created an attachment (id=18431)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18431action=view)
preprocessed source file
I'm not having much luck cutting this down more, sorry.
--
--- Comment #108 from lucier at math dot purdue dot edu 2009-08-27 01:18
---
direct.c contains a direct FFT; I've compiled the direct and inverse fft and I
ran it on arrays with 2^23 double-precision complex elements and
heine:~/programs/gcc/objdirs/bench-mainline-on-fft
--- Comment #109 from lucier at math dot purdue dot edu 2009-08-27 01:22
---
Created an attachment (id=18432)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18432action=view)
inner loop of direct.c with -fschedule-insns
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #110 from lucier at math dot purdue dot edu 2009-08-27 01:22
---
Created an attachment (id=18433)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18433action=view)
inner loop of direct.c without -fschedule-insns
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33928
--- Comment #34 from carrot at google dot com 2009-08-27 01:40 ---
There is one optimization that we can do without affecting the ABI and linker
compatibility. The delete destructor(D0) always contains the content of
complete desturctor(D1) followed by a function call to delete. So
62 matches
Mail list logo
