--- Comment #6 from spop at gcc dot gnu dot org 2009-12-18 08:29 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from spop at gcc dot gnu dot org 2009-12-18 08:29 ---
Subject: Bug 42180
Author: spop
Date: Fri Dec 18 08:28:45 2009
New Revision: 155339
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155339
Log:
Fix PR42180.
2009-12-18 Sebastian Pop
PR middle-end/42
155320
configure: error: libgmp not found or uses a different ABI.
make[2]: *** [configure-stage1-mpc] Error 1
make[1]: *** [stage1-bubble] Error 2
make: *** [bootstrap] Error 2
NOTE; in-tree mpc works if gmp/mpfr are installed & referenced with
--with-gmp/--with-mpfr.
--
Summary:
--- Comment #1 from pzhao at gcc dot gnu dot org 2009-12-18 08:50 ---
Subject: Bug 31665
Author: pzhao
Date: Fri Dec 18 08:50:24 2009
New Revision: 155340
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155340
Log:
cp/
2009-12-16 Shujing Zhao
PR c++/31665
* de
--- Comment #5 from burnus at gcc dot gnu dot org 2009-12-18 08:51 ---
Confirm. The bug report looks valid and the patch sensible. Cf. for
fstat/fstati64 the page:
http://msdn.microsoft.com/en-us/library/aa246905%28VS.60%29.aspx
Kai agrees that the patch looks OK and he checked that _fs
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-18 09:35
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Statu
--- Comment #11 from paolo at gcc dot gnu dot org 2009-12-18 09:41 ---
Subject: Bug 40088
Author: paolo
Date: Fri Dec 18 09:41:03 2009
New Revision: 155342
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155342
Log:
2009-12-18 Jimmy Guo
PR libstdc++/40088
* sr
--- Comment #12 from paolo dot carlini at oracle dot com 2009-12-18 09:51
---
David, I committed a patch which should alleviate the problem, any chance you
can tell us whether you are seeing an improvement?
More tweaks (within the C++0x model still) are possible, but seems hard to
impl
--- Comment #12 from burnus at gcc dot gnu dot org 2009-12-18 09:56 ---
> With the upcoming release of 4.5, I think it would be nice to fix/improve the
> translation related bugs now, i.e. this, PR38573 and PR40489.
>
> As I have no idea how to reproduce/check/whatever this kind of PR,
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-18 09:57
---
I meant C++03, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40088
--- Comment #11 from rainer at emrich-ebersheim dot de 2009-12-18 10:02
---
(In reply to comment #10)
> Should be fixed in SVN now. Rainer, please verify when you get a chance.
>
Today I will try to build a complete tool chain with shared libstdc++ enabled.
I will report back.
--
--- Comment #2 from burnus at gcc dot gnu dot org 2009-12-18 10:07 ---
Hmm, I cannot reproduce this with newer gfortran version. Using 4.2.1 I also
get:
1 2 3 5 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
however, already with 4.3.4 [gcc-4_3-branch revision 152973] I get:
1 2 3 5 5 5 5 0 0 0 0 0
The following valid code snippet triggers an ICE on trunk when compiled
with "-flto -g":
==
struct A
{
virtual ~A();
};
void foo()
{
struct B : A {};
B b;
}
==
bug.cc: In member function 'B':
bug.cc:8:16: internal compiler error: tree check:
--- Comment #2 from paolo dot carlini at oracle dot com 2009-12-18 11:20
---
Confirmed with r155343 on x86_64-linux. Seems a serious regression to me.
Note the snippet is missing a semicolon, fixed like this:
class A {
void f();
};
void A::f() {
A::A();
}
--
paolo dot carlini
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
--- Comment #3 from paolo dot carlini at oracle dot com 2009-12-18 11:48
---
... but indeed could well be invalid, thus a diagnostic issue only: in practice
some other compilers I have at hand disagree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
GCC (version 4.5.0 20091217) crashes when building binutils with message:
"lto1: internal compiler error: in get_resolution, at lto-streamer-in.c:1524".
--
Summary: ICE in get_resolution (lto)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-12-18
11:49 ---
Created an attachment (id=19343)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19343&action=view)
Preprocessed sources
Compile with `gcc src/* -flto -fuse-linker-plugin'
--
http://gcc.gnu.org/bug
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-12-18
11:50 ---
Created an attachment (id=19344)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19344&action=view)
Backtrace
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42426
--- Comment #1 from swamy dot sangamesh at gmail dot com 2009-12-18 12:30
---
Created an attachment (id=19345)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19345&action=view)
stack-trace
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42423
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-12-18 12:39 ---
Reopen. Still a 4.5 regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-12-18 12:40 ---
Re-open. Still a 4.5 regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-12-18 12:40 ---
Re-open. Still a 4.5 regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-18 12:41 ---
Re-open. Still a 4.5 regression (please close bugs only when they are fixed
where reported).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Known to work||4.4.2
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-12-18 12:48 ---
Confirmed. It'll be interesting on how this should interact with #include_next
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-18 13:10 ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154403
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-18 13:38 ---
Note added to gcc-4.5/changes.html (Caveats section).
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from jason at gcc dot gnu dot org 2009-12-18 14:06 ---
The testcase is ill-formed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Ass
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-12-18 14:14 ---
EDG and GCC 4.4 accept it. Can we do so as well with -fpermissive at least?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
--- Comment #4 from pault at gcc dot gnu dot org 2009-12-18 14:30 ---
What shall we do with this, gents?
A WONTFIX?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40165
--- Comment #19 from pault at gcc dot gnu dot org 2009-12-18 14:32 ---
Can this now be closed or has it transmogrified itself into something else?
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-18 14:35 ---
Joost,
The "name" of the error message is clearly marked by the '1'. I frankly do not
see any need to spend time on this one, so I am marking it as a WONTFIX.
If you want to revive it at another time, please do.
Pa
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--- Comment #14 from pault at gcc dot gnu dot org 2009-12-18 14:42 ---
Hi guys!
Do you want to suspend this PR or to junk it?
Let's get it out of the unconfirmed list.
Thanks
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40318
--- Comment #20 from rguenth at gcc dot gnu dot org 2009-12-18 14:45
---
There is still the issue about the 2nd testcase. It needs to be re-analyzed
and possibly simplified. But it's now a pure optimization issue, not a
frontend issue anymore.
--
rguenth at gcc dot gnu dot org cha
--- Comment #2 from pault at gcc dot gnu dot org 2009-12-18 14:45 ---
Hmmm! What shall we do with this?
IMHO we should issue a WONTFIX.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40319
--- Comment #4 from pault at gcc dot gnu dot org 2009-12-18 14:48 ---
I cannot see any point in retaining this PR against the gfortran target.
I am marking it, especially in light of Rainer's remarks, as WONTFIX.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
Wha
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
--- Comment #5 from burnus at gcc dot gnu dot org 2009-12-18 14:43 ---
I would like to see an option to silence gfortran in this regard - having it as
default warning is fine, but maybe some -Wno-deleted option could be added
then? Or like g95 and ifort have (gcc/g++ as well?) a fine tun
--- Comment #1 from pault at gcc dot gnu dot org 2009-12-18 14:53 ---
What do you want to do with this, Tobias?
Confirmed
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #37 from howarth at nitro dot med dot uc dot edu 2009-12-18
14:54 ---
I noticed that in libjava/sysdep/arm/backtrace.h, arm has its own definition of
_Unwind_FindEnclosingFunction. Could we use the same approach for darwin10 to
override the default _Unwind_FindEnclosingFunct
--- Comment #7 from jason at gcc dot gnu dot org 2009-12-18 15:20 ---
EDG accepts it in G++ mode, but not by default.
The patch I'm testing accepts it with -fpermissive.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42415
--- Comment #12 from rainer at emrich-ebersheim dot de 2009-12-18 15:29
---
(In reply to comment #11)
> (In reply to comment #10)
> > Should be fixed in SVN now. Rainer, please verify when you get a chance.
> >
>
> Today I will try to build a complete tool chain with shared libstdc++
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2009-12-18 15:38
---
I agree, closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-12-18 15:43
---
Created an attachment (id=19346)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19346&action=view)
patch to fix SCCVN issue
This patch fixes the SCCVN issue, I'm giving it more testing.
--
http://gcc.gnu
--- Comment #15 from sgk at troutmask dot apl dot washington dot edu
2009-12-18 15:52 ---
Subject: Re: Complex division by zero in gfortran returns wrong results
On Fri, Dec 18, 2009 at 02:42:15PM -, pault at gcc dot gnu dot org wrote:
>
> Do you want to suspend this PR or to jun
--- Comment #6 from ktietz at gcc dot gnu dot org 2009-12-18 15:53 ---
In mingw-w64 headers we do the following
#if !defined(__OBJC__) && !defined(__OBJC_BOOL) && !defined(__objc_INCLUDE_GNU)
#define BOOL WINBOOL
#endif
For local build for obj-c we use a patched objc.h defining __OBJC_B
--- Comment #8 from jason at gcc dot gnu dot org 2009-12-18 16:13 ---
Subject: Bug 42415
Author: jason
Date: Fri Dec 18 16:12:50 2009
New Revision: 155347
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155347
Log:
PR c++/42415
* call.c (build_new_method_call): Co
--- Comment #9 from jason at gcc dot gnu dot org 2009-12-18 16:16 ---
Fixed.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from don at drexel dot edu 2009-12-18 16:21 ---
Thanks for confirming this bug. I suspect that this issue may generate a bit
of discussion before an implementation plan is created. Interactions with
fixincludes may also need to be worked out. For reference I have writte
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #16 from ghazi at gcc dot gnu dot org 2009-12-18 17:16 ---
(In reply to comment #15)
> Now that MPC is required by gcc, I'll take a look
> at making gfortran give a consistent result when
> comparing its constant folding with generated code.
BTW, I put in some special-case c
GCC trunk gets a ICE when building SPEC CPU2000 test 301.apsi with "-O2
-fnon-call-exceptions -fpeel-loops -fexceptions", as demonstrated by this
minimized testcase:
SUBROUTINE TEST(HELP,WM,NZ)
IMPLICIT REAL*8 (A-H, O-Z)
REAL*8 HELP(NZ)
COMPLEX*16 WM(NZ)
DO K=1,NZ
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-12-18 18:27
---
Tobias, thanks for your description. I'm still a bit hazy on the details, but I
changed my tree according to what I picked up. Question is, how do I verify
that the issue described in the initial report is fixed?
Using gfortran 4.4.1, a string parameter passed to a subroutine is mangled when
an optional parameter is missing. I enclose a simplified example below.
In the original 2000+ line program, the string passed was the required string
plus the string from the following error checking call. In this
--- Comment #1 from kargl at gcc dot gnu dot org 2009-12-18 19:39 ---
Your program is non-conforming. You need to have an explicit interface
for the subroutine with an optional argument. Put your main program
in one file and the subroutine in another. When you compile the main
program
--- Comment #4 from jason at gcc dot gnu dot org 2009-12-18 20:50 ---
Subject: Bug 42062
Author: jason
Date: Fri Dec 18 20:49:58 2009
New Revision: 155349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155349
Log:
PR c++/28300
PR c++/42062
* pt.c (check_s
--- Comment #3 from jason at gcc dot gnu dot org 2009-12-18 20:50 ---
Subject: Bug 28300
Author: jason
Date: Fri Dec 18 20:49:58 2009
New Revision: 155349
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155349
Log:
PR c++/28300
PR c++/42062
* pt.c (check_s
--- Comment #10 from jason at gcc dot gnu dot org 2009-12-18 20:50 ---
Subject: Bug 42415
Author: jason
Date: Fri Dec 18 20:50:08 2009
New Revision: 155350
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155350
Log:
PR c++/42415
* g++.old-deja/g++.jason/temporary5
--- Comment #39 from dominiq at lps dot ens dot fr 2009-12-18 21:04 ---
The patch in comment #38 does not fix the speed issue: the code with the inner
loop is still 4 times slower than the code with the loop manually unrolled.
Note that the included test regtests successfully.
--
--- Comment #40 from matz at gcc dot gnu dot org 2009-12-18 21:40 ---
That's expected. There are three problems and the patch in comment #38 hacks
around only one of them.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
The testcase I'm going to attach is miscompiled with -m31 -O2 -fno-inline
-march=z9-109 -mtune=z10 (-march=z990 instead of -march=z9-109 too), aborts in
that case.
With sed 's/schedule-insns/no-schedule-insns/' works fine.
Fails on current branches/gcc-4_4-branch as well as redhat/gcc-4_4-branch, w
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-18 22:08 ---
Created an attachment (id=19347)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19347&action=view)
2fish.c
Simplified testcase from twofish's test. The optimize attribute is of course
not needed to reproduce it,
Command line:
g++ A.cpp B.cpp -fPIC -shared -O1 -flto
or
g++ A.cpp B.cpp -fPIC -shared -O1 -fwhopr
Tested revisions:
r155256, with checking - crash
r155248, with checking - crash
r155248, without checking - OK
r154830, with checking - crash
Output:
$ /mnt/svn/gcc-trunk/binary-155256-lto/bin/g++
--- Comment #1 from zsojka at seznam dot cz 2009-12-18 22:12 ---
Created an attachment (id=19348)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19348&action=view)
A.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42430
--- Comment #2 from zsojka at seznam dot cz 2009-12-18 22:12 ---
Created an attachment (id=19349)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19349&action=view)
B.cpp
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42430
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-12-18 22:27 ---
This code is invalid C++ code as it is a violation of the one definition rule.
That is Pool::Get returns two different types in the two different translation
units.
--
pinskia at gcc dot gnu dot org changed:
When compiled with current trunk and options "-m64 -O2 -ftree-vectorize
-maltivec -fdata-sections", CPU2000 test 200.sixtrack gets wrong results and
segfaults before finishing. I've reproduced the failure on POWER6 and POWER7
hardware. The source file that is miscompiled is midbloc6.f. If I add
--- Comment #1 from janis at gcc dot gnu dot org 2009-12-18 23:03 ---
Oh yeah, 176.gcc fails with the same options. With test input it runs for a
few minutes instead of a couple of seconds, and the results are wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42431
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|wrong code for 200.sixtrack |[4.5 Regression] wrong code
|with vectorization and
--- Comment #5 from jason at gcc dot gnu dot org 2009-12-18 23:14 ---
Fixed for 4.5, not backporting invalid-code changes.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-18 23:15 ---
We could diagnose this, but the C++ standard doesn't require a diagnostic (and
with functions it unfortunately happens too common and would be very noisy).
--
rguenth at gcc dot gnu dot org changed:
W
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-12-18 23:17 ---
Btw, we have similar issues with the SLES11 gcc 4.3 compiler and openssl.
See https://bugzilla.novell.com/show_bug.cgi?id=457410
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|invalid assembly code for |[4.5 Regression] invalid
|301.apsi for -fnon-call-
--- Comment #41 from rguenth at gcc dot gnu dot org 2009-12-18 23:44
---
Indeed. The PRE issue could be fixed by fixing PR38819 not in the way it is
done now but "properly" detect the invalid situations during ANTIC computation
and simply never mark trapping expressions so. At the cur
--- Comment #38 from howarth at nitro dot med dot uc dot edu 2009-12-19
00:35 ---
I've confirmed that both the WalkerTest failures and the gcj compiler crashes
on java code are eliminated on darwin10 if I duplicate the code for
_Unwind_FindEnclosingFunction() as _darwin10_Unwind_FindEnc
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-12-19 00:41 ---
The following seems to fix it for some reason.
Index: lto-streamer-out.c
===
--- lto-streamer-out.c (revision 155347)
+++ lto-streamer-out.c (working
--- Comment #5 from matz at gcc dot gnu dot org 2009-12-19 01:19 ---
To explain: the miscompilation is a result of the cloner (when cloning for the
find() call) creating a new tree for a local static variable (the 'm' in
main). After inlining we have:
if ( &mD.2293._M_tD.2062._M_implD
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-12-19
01:20 ---
I guess this option should have a few warning levels. For example,
-Wcovered-headers (or -Wcovered-headers=1, which is the same) will not warn
about fixed and GCC's private include files.
--
http://gcc.
--- Comment #6 from matz at gcc dot gnu dot org 2009-12-19 02:33 ---
Ah, because the references to trees are not handled via the write_cache
hashtable, but via the per-kind stream (in output_block.decl_state), which
is not realloced on create_output_block, but only on
lto_push/pop_out_de
In ISO C99 6.5.2.3 paragraph 5, it is mentioned that:
``One special guarantee is made in order to simplify the use of unions: if a
union contains several structures that share a common initial sequence (see
below), and if the union object currently contains one of these structures, it
is permitted
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-19 03:45 ---
*** This bug has been marked as a duplicate of 14319 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-12-19 03:45 ---
*** Bug 42432 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
85 matches
Mail list logo
