--- Comment #8 from bje at gcc dot gnu dot org 2009-07-08 06:07 ---
All limits-fndefn.c tests now pass (lto revision 149354).
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-08 06:08 ---
Still a problem.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-08 06:08 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-08 06:09 ---
Whoops, confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|dnovillo at google dot com |bje at gcc dot gnu dot org
Status|UNCONFIRMED
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org
|dot org
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org
|dot org
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-08 06:21 ---
PASS: g++.dg/opt/devirt1.C (test for excess errors)
(in lto revision 149354)
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-08 06:23 ---
Fixed in lto revision 149354.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-08 06:24 ---
This .ii file now produces errors due to changes in the GCC 4.4 C++ front-end.
Could you please try again and report back? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39003
If the following code is compiled with -Os for ARM or ColdFire, the exit
condition for the loop is removed.
Replacing *tbl++ with tbl[i] or using unsigned long instead of volatile
unsigned long does not show the problem.
I suspect the post-increment optimization to be the problem, because the
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-08 07:36 ---
I can reproduce the ICE with 4.1, 4.2 and 4.3 - but it no longer gives an ICE
with 4.4 or 4.5.
* * *
However, there is also a bug in 4.4: It simply compiles.
Expected: Either an error of the form (NAG f95)
--- Comment #10 from burnus at gcc dot gnu dot org 2009-07-08 08:00 ---
I think one can consider supporting non-signed zeros as extension, similar to
ifort which has:
-assume nominus0The compiler uses Fortran 90/77 standard
semantics in
Sent from my iPhone
On Jul 8, 2009, at 12:32 AM, bastian dot schick at sciopta dot com gcc-bugzi...@gcc.gnu.org
wrote:
If the following code is compiled with -Os for ARM or ColdFire, the
exit
condition for the loop is removed.
Replacing *tbl++ with tbl[i] or using unsigned long instead
--- Comment #1 from pinskia at gmail dot com 2009-07-08 08:13 ---
Subject: Re: New: Optimizer handles loops with volatiles and post-incr. wrong
Sent from my iPhone
On Jul 8, 2009, at 12:32 AM, bastian dot schick at sciopta dot com
gcc-bugzi...@gcc.gnu.org
wrote:
If the
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-08 08:21 ---
patches should be sent to gcc-patc...@gcc.gnu.org with a changelog entry
and a note how it was tested.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40677
--- Comment #2 from bastian dot schick at sciopta dot com 2009-07-08 08:24
---
(In reply to comment #1)
Sent from my iPhone
Oh, dude (which one :-)
On Jul 8, 2009, at 12:32 AM, bastian dot schick at sciopta dot com
gcc-bugzi...@gcc.gnu.org
wrote:
If the following code is
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-08 08:25 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2009-07-08 08:49 ---
On trunk with -fno-tree-vrp I see the correct code being generated.
bs:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
--- Comment #4 from bastian dot schick at sciopta dot com 2009-07-08 09:06
---
(In reply to comment #3)
On trunk with -fno-tree-vrp I see the correct code being generated.
It seems to be related to Bug #30785 (test for null pointer).
--
--- Comment #3 from rubidium at openttd dot org 2009-07-08 09:12 ---
I cannot reproduce this error anymore in gcc-lto (lto merged with rev 149291)
4.5.0 20090706 (experimental) revision 149340.
However... I don't have the setup I've ran the previous test on, as such I have
build it
--- Comment #5 from ramana at gcc dot gnu dot org 2009-07-08 09:12 ---
Richi,
Can you comment on this one ?
Ramana
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Compile the attached source code with options -Os -mthumb -march=armv5te, gcc
generates:
push{r3, r4, r5, lr}
.LCFI0:
mov r4, r0
ldr r0, [r0]
bl _Z3foof
ldr r1, [r4, #4]
@ sp needed for prologue
add r5, r0, #0
--- Comment #1 from carrot at google dot com 2009-07-08 09:36 ---
Created an attachment (id=18155)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18155action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40680
--- Comment #3 from pault at gcc dot gnu dot org 2009-07-08 09:48 ---
Well. I suppose that I should accept the bug :-)
I will commit the fix to 4.4 over the weekend, so please try to test it to
destruction on 4.5.
Paul
--
pault at gcc dot gnu dot org changed:
What
--- Comment #6 from mikpe at it dot uu dot se 2009-07-08 09:59 ---
(In reply to comment #2)
Replacing *tbl++ by tbl[i] gives this ARM code:
.L2:
mov r3, #10
str r3, [r2], #4
cmp r2, #0
bne .L2
bx lr
See, gcc knows
--- Comment #2 from ramana at gcc dot gnu dot org 2009-07-08 10:00 ---
However Confirmed with trunk for Thumb1. The extra move doesn't appear for ARM
or Thumb2 .
The code below is what is generated for Thumb2 or ARM .
.type _ZN3CCC5funcAEv, %function
_ZN3CCC5funcAEv:
--- Comment #1 from ramana at gcc dot gnu dot org 2009-07-08 10:01 ---
Can you attach a pre-processed file for someone to look at this ? This bug
report seems incomplete.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-08 10:10 ---
Indeed the overflow invokes undefined behavior.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from Thomas dot Lange at sun dot com 2009-07-08 10:23
---
(In reply to comment #2)
why don't you add a 'virtual'
to your destructor and int f(int) functions, because they are implicitly
virtual anyway'.
That is exactly the point this is about!
I want a way so the
--- Comment #4 from Thomas dot Lange at sun dot com 2009-07-08 10:30
---
Side note: Of course having such an option is much more useful where the
declaration of class A and B are in different header files and probably even in
different modules.
(For example: such cases are often found
Bug in lto revision 149340 (gcc 4.5 revision 149291 works fine)
The used command line:
/usr/local/lto/bin/g++-lto -v -save-temps -O2 -fomit-frame-pointer -flto -DUNIX
-Wall -Wno-multichar -Wsign-compare -Wundef -Wwrite-strings -Wpointer-arith
-Wno-uninitialized -W -Wno-unused-parameter -Wformat=2
--- Comment #1 from rubidium at openttd dot org 2009-07-08 10:42 ---
Created an attachment (id=18156)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18156action=view)
The .ii file of save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40681
--- Comment #6 from hp at gcc dot gnu dot org 2009-07-08 10:47 ---
(In reply to comment #0)
If it's just about the version, perhaps you can make -V working again.
Requires a working --enable-version-specific-runtime-libs of course. :)
--
--- Comment #7 from hp at gcc dot gnu dot org 2009-07-08 10:49 ---
(In reply to comment #6)
If it's just about the version, perhaps you can make -V working again.
Oh same version. Change the above to make -b working again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
In a recent discussion on comp.std.c++
rvalue references returned from a function,
as pointed by Niels Dekker and Micael Dark,
a defect report:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#391
was accepted into C++0x WP. This has a significant impact on GCC.
The current
--- Comment #4 from bje at gcc dot gnu dot org 2009-07-08 11:15 ---
Reported as fixed by the original submitter.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from sezeroz at gmail dot com 2009-07-08 11:37 ---
Will there be a backport of this to the branches 4.3 and 4.4?
--
sezeroz at gmail dot com changed:
What|Removed |Added
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-08 11:41
---
Note, in general work on C++0x features doesn't really belong to Bugzilla,
unless existing code crashes on new testcases, things like that. You understand
that in general the situation would otherwise quickly
--- Comment #4 from dominiq at lps dot ens dot fr 2009-07-08 11:47 ---
It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and
Intel64(?), see
http://gcc.gnu.org/ml/gcc-testresults/2009-07/msg00755.html
http://gcc.gnu.org/ml/gcc-regression/2009-07/msg00078.html
--- Comment #3 from bje at gcc dot gnu dot org 2009-07-08 11:49 ---
This is fixed in lto revision 149354. I ran make check-gcc and watched /tmp.
Temporary files were removed as the testsuite ran.
--
bje at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from kkojima at gcc dot gnu dot org 2009-07-08 11:54
---
I don't think this is a regression, unfortunately.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
--- Comment #5 from burnus at gcc dot gnu dot org 2009-07-08 12:37 ---
(In reply to comment #4)
It seems that gfortran.dg/proc_ptr_21.f90 is failing on i686-pc-linux-gnu and
Intel64(?), see
I can - somewhat - reproduce it. It does not fail but valgrind shows
(x86-64-linux and
--- Comment #2 from dragan at plusplus dot co dot yu 2009-07-08 12:38
---
Although this is a feature request in the context that the old behavior
was correctly implemented and it will be different in C++0x, it still presents
a bug in the current C++0x implementation. It creates copies
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-08 12:47
---
To be clear, I'm not telling you anything specific about the development
process. Actually, that's exactly the point, this is ongoing development of
experimental features, no guarantees, no guarantees of
--- Comment #8 from bastian dot schick at sciopta dot com 2009-07-08 13:06
---
(In reply to comment #6)
(In reply to comment #2)
Replacing *tbl++ by tbl[i] gives this ARM code:
.L2:
mov r3, #10
str r3, [r2], #4
cmp r2, #0
bne
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-08 13:11 ---
induction variable optimization is different w/o volatile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40679
On Linux/ia32, revision 149362 gave
FAIL: gfortran.dg/proc_ptr_21.f90 -O1 execution test
FAIL: gfortran.dg/proc_ptr_21.f90 -O2 execution test
FAIL: gfortran.dg/proc_ptr_21.f90 -O3 -fomit-frame-pointer execution test
FAIL: gfortran.dg/proc_ptr_21.f90 -O3 -fomit-frame-pointer
--- Comment #3 from pault at gcc dot gnu dot org 2009-07-08 13:22 ---
Created an attachment (id=18157)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18157action=view)
Fix for bug - not regtested yet
This handles host_assoc_function_*.f90 correctly but is not yet regtested.
The
--- Comment #5 from manu at gcc dot gnu dot org 2009-07-08 13:25 ---
(In reply to comment #3)
Note that getInt is completely inlined and there is no location involving
that function available anymore :/ The difficulties of C++ and late
diagnostics ...
Don't we keep
--- Comment #1 from dominiq at lps dot ens dot fr 2009-07-08 13:28 ---
See pr40591 comments #4 and #5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40683
--- Comment #8 from manu at gcc dot gnu dot org 2009-07-08 13:28 ---
I am going to close this as FIXED, since it cannot be reproduced anymore. If
anyone manages to reproduce it in GCC 4.5, please reopen.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from pault at gcc dot gnu dot org 2009-07-08 13:28 ---
(In reply to comment #5)
That is solved by adding:
i = 0
to subroutine test (while any other number causes the abortion).
Indeed - that was in the test originally; I do not know what happened to it.
I'll put
--- Comment #2 from pault at gcc dot gnu dot org 2009-07-08 13:29 ---
(In reply to comment #1)
See pr40591 comments #4 and #5.
Indeed! I'll fix it tonight.
Thanks, HJ
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dominiq at lps dot ens dot fr 2009-07-08 13:31 ---
pr40683 is a duplicate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40591
--- Comment #4 from hjl at gcc dot gnu dot org 2009-07-08 14:30 ---
Subject: Bug 40557
Author: hjl
Date: Wed Jul 8 14:30:12 2009
New Revision: 149371
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149371
Log:
2009-07-08 H.J. Lu hongjiu...@intel.com
Backport from
--- Comment #11 from burnus at gcc dot gnu dot org 2009-07-08 14:55 ---
Created an attachment (id=18158)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18158action=view)
Patch - lightly tested
Attached patch fixes the problem [independent of
-f(no-)signed-zeros/-ffast-math].
The
--- Comment #4 from edmar at freescale dot com 2009-07-08 15:06 ---
I did not run any test suite, nor prepared any test case suitable for inclusion
in dejagnu suite.
I opened a bug hopping the information I gave would help resolve the issue
faster.
--
// { dg-options -std=c++0x }
struct A
{
};
template typename S, typename T, typename U, typename S::v = S::v::s
typename S::A
foo (S c, T t, U u)
{
}
struct B
{
struct C
{
template typename U
C (U t)
{
A a;
A b = foo (this, a, t);
}
} c;
B () : c (A ())
{
The following testcase fails on g++ 4.4.0 and 4.3.2:
#include cstdlib
enum Enum {
Foo
};
class A
{
public:
A(int y) : x(y) {}
explicit A(Enum) : x(1) {}
int x;
};
static void fun(A a = Foo)
{
if (a.x != static_castint(Foo)) {
abort();
}
}
int
--- Comment #16 from rth at gcc dot gnu dot org 2009-07-08 16:41 ---
Subject: Bug 38900
Author: rth
Date: Wed Jul 8 16:41:23 2009
New Revision: 149373
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149373
Log:
PR target/38900
* config/i386/i386.h
--- Comment #7 from mikpe at it dot uu dot se 2009-07-08 16:43 ---
4.4-20090630 plus this fix bootstrapped fine, fixed the test case, built a
working 2.6.31-rc2 Linux kernel, and built a working Erlang VM.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
--- Comment #12 from kargl at gcc dot gnu dot org 2009-07-08 16:49 ---
Created an attachment (id=18160)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18160action=view)
dejagnu testr case
Test that sign(x, +-0) conforms to F95.
--
--- Comment #13 from kargl at gcc dot gnu dot org 2009-07-08 16:50 ---
Created an attachment (id=18161)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18161action=view)
dejagnu test case
Test case for sign(x,+-0) when the new -fno-sign-zero option is used.
--
--- Comment #14 from kargl at gcc dot gnu dot org 2009-07-08 16:56 ---
(In reply to comment #11)
Created an attachment (id=18158)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18158action=view) [edit]
Patch - lightly tested
Attached patch fixes the problem [independent of
--- Comment #17 from rth at gcc dot gnu dot org 2009-07-08 16:59 ---
Subject: Bug 38900
Author: rth
Date: Wed Jul 8 16:59:15 2009
New Revision: 149374
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149374
Log:
PR target/38900
* config/i386/i386.h
--- Comment #18 from rth at gcc dot gnu dot org 2009-07-08 17:03 ---
Fixed.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from janis at gcc dot gnu dot org 2009-07-08 17:08 ---
I can reproduce the error with plugin.exp not struct-layout-1.exp. This fixes
it for me, does it for you guys?
Index: gcc/testsuite/lib/gcc.exp
===
---
--- Comment #8 from blp at cs dot stanford dot edu 2009-07-08 17:30 ---
Wow, that's amazingly fast turnaround. Thanks so much guys!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
--- Comment #4 from tjruwase at google dot com 2009-07-08 17:59 ---
Subject: Re: [4.5 Regression] Errors in make -k
check-gcc RUNTESTFLAGS=plugin.exp
Your fix works for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40625
--- Comment #1 from mark at gcc dot gnu dot org 2009-07-08 18:08 ---
Subject: Bug 40659
Author: mark
Date: Wed Jul 8 18:07:47 2009
New Revision: 149377
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=149377
Log:
2009-07-08 Mark Wielaard m...@redhat.com
PR debug/40659
Our HDF5 software has been having some data conversion problem with GCC's
optimization for a few years. One example is to convert data from short to
int. You can find the program at
ftp://ftp.hdfgroup.uiuc.edu/pub/outgoing/slu/tmp/ctest.c
When I use gcc -O2 or gcc -O3 to compile it, I get
--- Comment #2 from mark at gcc dot gnu dot org 2009-07-08 18:21 ---
Patch pushed.
--
mark at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-08 18:22 ---
You are violating C/C++ aliasing rules:
d = (uint8_t*)aligned;
/* This line causes the trouble. */
*((int*)d) = (int)(*((short*)s));
You are writing into a long long via an int which
Hi,
I think there is a bug in g++ 4.4 concerning the implementation of initializer
list. N2672
The following program does not compiles, but it should be accepted by g++.
// /opt/gcc-4.4/bin/g++ --std=c++0x -Wall
int main()
{
class X
{
public:
X(): data {1,2,3,4,5} {}
private:
const
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-08 20:38 ---
Before filing more bugs please verify the bugs exist on a recent version
of the development trunk for GCC 4.5. C++0x is considered incomplete
technology preview only.
--
On powerpc*-unknown-linux-gnu several vectorization tests ICE in verify_stmts
after the error message invalid conversion in gimple call:
gcc.dg/vect/no-scevccp-outer-7.c
gcc.dg/vect/no-scevccp-outer-13.c
gcc.dg/vect/slp-perm-1.c
gcc.dg/vect/slp-perm-2.c
--- Comment #4 from janis at gcc dot gnu dot org 2009-07-08 20:46 ---
On powerpc*-linux this test begins failing in the same way with this patch:
http://gcc.gnu.org/viewcvs?view=revrev=146831
r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009)
--
--- Comment #2 from janis at gcc dot gnu dot org 2009-07-08 20:46 ---
On powerpc*-linux the test begins to fail in the same way with this patch:
http://gcc.gnu.org/viewcvs?view=revrev=146831
r146831 | rguenth | 2009-04-27 11:18:38 + (Mon, 27 Apr 2009)
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-07-08 20:49 ---
I think this is really PR 30210.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40690
--- Comment #16 from burnus at gcc dot gnu dot org 2009-07-08 20:55 ---
Close as FIXED (on the trunk [= 4.5]).
Greg, thanks for the report. Using a 4.5/trunk build (e.g. one of the nightly
builds) gfortran will offer the option -fno-sign-zero which allows your
program to work.
--- Comment #3 from bernhard dot merkle at googlemail dot com 2009-07-08
20:56 ---
makes sense, thanks for the hint.
is there doc to which N papers the 4.5 trunk relates ?
e.g. like http://gcc.gnu.org/projects/cxx0x.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40689
Use of operator! (logical not) from valarray with slice fails. For example,
--
#include valarray
void test01()
{
const std::valarrayint vi(12);
std::valarraybool vb1(12);
std::valarraybool vb2(3);
std::slice s(0,3,4);
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-07-08 21:03 ---
It is.
*** This bug has been marked as a duplicate of 30210 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-07-08 21:03
---
*** Bug 40690 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from gdsjaar at sandia dot gov 2009-07-08 21:03 ---
Subject: Re: Support -fnosign-zero for SIGN
intrinsic for Fortran 77 compatibility
Thanks for the quick response. I agree that the ultimate fix is to
remove that idiom from the code; however, when dealing with
--- Comment #17 from meissner at linux dot vnet dot ibm dot com 2009-07-08
23:42 ---
Subject: Re: [4.5 Regression] Altivec builtins have inaccurate return types
On Wed, Jul 08, 2009 at 09:04:03PM -, rguenth at gcc dot gnu dot org wrote:
--- Comment #16 from rguenth at
--- Comment #1 from m dot rosellini at f5 dot com 2009-07-09 00:10 ---
I forgot to add: You need to compile this with -O2 and -march=pentium.
The way that negative constants are handled in the code emitted for
__sync_blah_and_blah is incorrect when the pointer type is 64-bits and the
--- Comment #6 from bje at gcc dot gnu dot org 2009-07-09 00:10 ---
Confirmed.
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-09 00:14 ---
Confirmed. The proposed fix is not correct, though, as the type of the first
argument to munmap _is_ void* according to POSIX.
--
bje at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-09 00:15 ---
Falk, can you please check again with the tip of the lto branch? I don't have
access to an Alpha system to check for myself. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39108
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-09 00:35
---
To be sure, let's CC Jason about these auto issues...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-09 00:35
---
To be sure, let's CC Jason about these auto issues...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-09 00:36
---
And again...
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--
bje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from bje at gcc dot gnu dot org 2009-07-09 05:09 ---
Building with --with-libelf is the right approach. I don't think it works 100%
correctly, though, so I will take this bug and investigate.
--
bje at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from bje at gcc dot gnu dot org 2009-07-09 05:10 ---
Rainer, can you please re-check this against the tip of the lto branch and
report back? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39025
--- Comment #3 from bje at gcc dot gnu dot org 2009-07-09 05:38 ---
On powerpc-linux, the original ICE has been replaced with:
$ ./xgcc -B. -flto -shared ctanf.o ctanhl.o ctanh.o
lto1: internal compiler error: in lto_read_file_options, at lto-opts.c:348
Please submit a full bug report,
1 - 100 of 103 matches
Mail list logo
