--- Comment #11 from bdubbs at linuxfromscratch dot org 2010-05-24 06:32
---
Updated to gcc (GCC) 4.5.1 20100524 (prerelease) but still have the problem.
There is something about -Os that triggers the kernel panic in
arch/x86/kernel/tsc.c
I tried to disable all -O2 options after -Os
--- Comment #7 from ttsiodras at gmail dot com 2010-05-24 07:24 ---
From my two tests in FreeBSD and Arch Linux, it appears that the -flto bug
that is triggered on my renderer, has occured with the 20100520 (prerelease)
commits.
I hope this helps
Is there anything else I can
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-24 07:45 ---
Can't reproduce with either branches/gcc-4_4-branch or
branches/redhat/gcc-4_4-branch any more.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from paul dot richard dot thomas at gmail dot com
2010-05-24 08:31 ---
Subject: Re: Missing interface not detected in call to
same file function
With -fwhole-file, we get for the short testcase:
../pr36553/pr36553.f90:2.9:
print *, f( (/ 0.0, 1.0/) )
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-24 08:52 ---
I think DW_AT_allocated would be wrong for C VLAs, they don't have allocated
property like Fortran arrays.
The problems I see are:
1) for -O0 we don't do any var-tracking, while we should be tracking
i) variables
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-24 08:58 ---
Current trunk prints fp=optimized out, which is correct (given that the
argument is passed in %eax using regparm calling conventions and the register
has been/could be clobbered by the call).
--
jakub at gcc dot
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-24 09:01 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from mikpe at it dot uu dot se 2010-05-24 09:31 ---
Bisection identified r159600 as the source of the failure on sparc64:
Author: rsandifo
Date: Wed May 19 21:08:53 2010
New Revision: 159600
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159600
Log:
gcc/
*
--- Comment #8 from bmei at broadcom dot com 2010-05-24 09:31 ---
I integrated Dave's patch into LD with some modification (only emit those with
LTO sections) and hacked collect2 to support that. The size gain of LTO, our
main concern, is quite limited for our application. Large amount
--- Comment #11 from jamborm at gcc dot gnu dot org 2010-05-24 09:43
---
(In reply to comment #9)
(In reply to comment #7)
This is now fixed on both the trunk and the 4.5 branch.
this commit produces broken libkhtml.so.5.4.0 from kdelibs-4.4.3.
in details, it produces
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-05-24 10:44
---
(In reply to comment #12)
With -fwhole-file, we get for the short testcase:
../pr36553/pr36553.f90:2.9:
print *, f( (/ 0.0, 1.0/) )
1
Error: The reference to function 'f' at (1) either needs an
the recent gcc-4.5-branch produces broken libkhtml.so.5.4.0 from kdelibs-4.4.3.
afaics it produces different/broken binaries for khtml/css/parser.cpp
and khtml/svg/SVGGradientElement.cpp.
finally we get a nice GPF during knode/kmail/konqueror startup:
[KCrash Handler]
#5 memcpy () at
--- Comment #1 from pluto at agmk dot net 2010-05-24 11:02 ---
Created an attachment (id=20732)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20732action=view)
preprocessed parser from kdelibs sources.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
--- Comment #12 from pluto at agmk dot net 2010-05-24 11:04 ---
(From update of attachment 20731)
moved to separated PR44258.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-24 11:13 ---
Created an attachment (id=20733)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20733action=view)
gcc46-pr41048.patch
Untested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41048
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-24 11:13 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-24 11:46 ---
most likely this is a duplicate of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
and potentially an LE/BE issue given that it's not reported on *x86*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.5.1
Known to work||4.5.0
--- Comment #2 from arekm at pld-linux dot org 2010-05-24 12:14 ---
In meantime - is reversing the problematic gcc commit a sane thing to do for a
gcc user? (from what I understand it was simply a better optimization and no
real bugfix, right?)
--
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-24 12:15 ---
(In reply to comment #8)
I integrated Dave's patch into LD with some modification (only emit those with
LTO sections) and hacked collect2 to support that. The size gain of LTO, our
main concern, is quite limited
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-24 12:18 ---
(In reply to comment #6)
Well, I added nostdlib and removed all libraries from the cmd line, but
still:
bash$ g++ -r -nostdlib -O3 -g -Wall -Wextra -fomit-frame-pointer -ffast-math
-funsafe-math-optimizations
--- Comment #9 from rguenth at gcc dot gnu dot org 2010-05-24 12:24 ---
Btw, it reccurs to me that the issue will be fixed by
http://gcc.gnu.org/viewcvs/trunk/gcc/lto/lto.c?r1=158729r2=158728pathrev=158729
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44256
--- Comment #12 from pault at gcc dot gnu dot org 2010-05-24 12:31 ---
Created an attachment (id=20734)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20734action=view)
Fix for this PR and PR40011 #42
This patch regtests OK apart from some peculiarities in proc_ptr_comp_9.f90 and
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-24 12:34
---
Subject: Bug 44256
Author: rguenth
Date: Mon May 24 12:34:34 2010
New Revision: 159779
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159779
Log:
2010-05-24 Richard Guenther rguent...@suse.de
PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-24 12:35
---
The next snapshot will pick up this fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44256
--- Comment #24 from rguenth at gcc dot gnu dot org 2010-05-24 12:56
---
(In reply to comment #23)
Just wondering after so many adjustments - is the bug going to be fixed ?
Very unlikely. If there is a small patch that fixed it for 4.4.0 then
that can possibly be back-ported (but
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-05-24 12:57 ---
(In reply to comment #2)
In meantime - is reversing the problematic gcc commit a sane thing to do for a
gcc user? (from what I understand it was simply a better optimization and no
real bugfix, right?)
If
libiberty/pex-unix.c has some alpha64(ia64?)-dec-vms specific
code, that fails to compile for me due to mismatched typedefs:
+ make
if [ x != x ]; then \
alpha64-dec-vms-gcc -c -DHAVE_CONFIG_H -I.
-I/src/binutils/src/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
--- Comment #3 from sandra at codesourcery dot com 2010-05-24 13:08 ---
I'm testing a fix for this (better comparison combination logic in the
ifconvert pass).
--
sandra at codesourcery dot com changed:
What|Removed |Added
--- Comment #13 from sandra at codesourcery dot com 2010-05-24 13:21
---
I'm working on a patch that fixes the test case in comment #5 (originally filed
as PR 39874) and some other test cases by improving the comparison combination
logic in both tree-ssa-ifcombine and tree-ssa-reassoc.
If compiled without -O3 option, this code snippet works fine (running
executable will print i=11223344, bswap=44332211)
If compiled with -O3 option, executable will print i=11223344,
bswap=.
Checked on 4.4.1 x86 and 4.4.3 x64.
#include stdio.h
struct int32_bytes
{
int byte1:8;
--- Comment #10 from bmei at broadcom dot com 2010-05-24 13:29 ---
annotating functions with externally_visible sounds a bit difficult to
maintain. Programmer needs to know whether a function is used outside of LTO
objects. This can change over time and extra efforts are needed to keep
--- Comment #1 from dennis at conus dot info 2010-05-24 13:30 ---
The code 4.4.1 x86 generating (with -O3 option) for bswap() function I
mentioned earlier is strange too:
; bswap(unsigned int)
public _Z5bswapj
_Z5bswapj proc near
var_4 = dword ptr -4
--- Comment #12 from ttsiodras at gmail dot com 2010-05-24 13:41 ---
I am at work, so I did a fresh compilation of GCC4.5 from the 20050520
snapshot under my Debian stable using:
../configure --prefix=/opt/gcc45 --enable-languages=c,c++ --enable-lto
The bug still happens, even if I
--- Comment #13 from ttsiodras at gmail dot com 2010-05-24 13:44 ---
I meant 20100520, obviously, not 20050520 (no flto back then! :-)
Anyway, if I understood correctly, I should wait for the next snapshot... ETA?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44256
--- Comment #14 from ttsiodras at gmail dot com 2010-05-24 13:47 ---
And now that we see that it happens even with one object file,
here is the preprocessed (.ii) for the code behind this object file:
http://users.softlab.ntua.gr/~ttsiod/renderer.ii.gz
--
--- Comment #2 from xinping dot huang at gmail dot com 2010-05-24 13:51
---
Subject: Re: Strange behavior on bit fields sructures.
My gcc 4.4.4 generate the correct binary and get the correct result
even with -O3 option.
Wesley
2010/5/24 dennis at conus dot info
--- Comment #3 from xinping dot huang at gmail dot com 2010-05-24 13:53
---
Subject: Re: Strange behavior on bit fields structures
Sorry I made a mistake here, it works on 32bit mode, but failed on the
64bit mode.
Wesley
2010/5/24 xinping dot huang at gmail dot com
--- Comment #14 from dfranke at gcc dot gnu dot org 2010-05-24 14:03
---
(In reply to comment #13)
Should we close this?
Yes, this is testcase gfortran.dg/whole_file_2.f90.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from iains at gcc dot gnu dot org 2010-05-24 14:36 ---
Subject: Bug 43602
Author: iains
Date: Mon May 24 14:36:32 2010
New Revision: 159781
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159781
Log:
2010-05-24 Iain Sandoe ia...@gcc.gnu.org
PR
--- Comment #22 from iains at gcc dot gnu dot org 2010-05-24 14:36 ---
Subject: Bug 44132
Author: iains
Date: Mon May 24 14:36:32 2010
New Revision: 159781
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159781
Log:
2010-05-24 Iain Sandoe ia...@gcc.gnu.org
PR
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-24 14:38 ---
Created an attachment (id=20735)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20735action=view)
gcc46-pr42801.patch
Patch for the -O2 issue.
The standard says:
Concrete inlined instance entries may omit
--- Comment #6 from danglin at gcc dot gnu dot org 2010-05-24 15:28 ---
this was caused by the maxtsiz limit.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from danglin at gcc dot gnu dot org 2010-05-24 15:36 ---
I have also seen this error.
It's a bit of a puzzle. A segfault occurs in the startup of
the a.out file run by configure. A null constructor address
is loaded from the constructor table causing the fault.
--
--- Comment #4 from schwab at linux-m68k dot org 2010-05-24 15:48 ---
*** This bug has been marked as a duplicate of 21920 ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #152 from schwab at linux-m68k dot org 2010-05-24 15:48 ---
*** Bug 44260 has been marked as a duplicate of this bug. ***
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #4 from mikpe at it dot uu dot se 2010-05-24 16:16 ---
(In reply to comment #3)
most likely this is a duplicate of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229
and potentially an LE/BE issue given that it's not reported on *x86*
However:
1. I see the failure on
--- Comment #5 from mikpe at it dot uu dot se 2010-05-24 16:21 ---
Comparing stage2-libiberty/cp-demangle.o with stage3-libiberty/cp-demangle.o
shows that one instruction has had it's source operands swapped:
objdump -d stage2-libiberty/cp-demangle.o a
objdump -d
The following testcase is an example of code used in a glibc testcase. I'm
trying hard to shake out the bugs in the glibc testsuite for debian, and one
testsuite failure looks like a compiler issue.
The expected behaviour is for the testcase to print the raw IEEE754 value of
-NAN.
The observed
--- Comment #28 from uros at gcc dot gnu dot org 2010-05-24 16:23 ---
Subject: Bug 43733
Author: uros
Date: Mon May 24 16:22:30 2010
New Revision: 159785
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159785
Log:
Backport from mainline:
2010-05-20 Uros Bizjak
--- Comment #29 from uros at gcc dot gnu dot org 2010-05-24 16:26 ---
Subject: Bug 43733
Author: uros
Date: Mon May 24 16:26:17 2010
New Revision: 159786
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159786
Log:
Backport from mainline:
2010-05-20 Uros Bizjak
--- Comment #30 from uros at gcc dot gnu dot org 2010-05-24 16:29 ---
Subject: Bug 43733
Author: uros
Date: Mon May 24 16:28:53 2010
New Revision: 159787
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159787
Log:
Backport from mainline:
2010-05-20 Uros Bizjak
--- Comment #31 from ubizjak at gmail dot com 2010-05-24 16:31 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #11 from rguenther at suse dot de 2010-05-24 17:27 ---
Subject: Re: collect2 does not handle static libraries
On Mon, 24 May 2010, bmei at broadcom dot com wrote:
--- Comment #10 from bmei at broadcom dot com 2010-05-24 13:29 ---
annotating functions with
--- Comment #23 from iains at gcc dot gnu dot org 2010-05-24 17:27 ---
Created an attachment (id=20736)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20736action=view)
candidate solution
OK, so comment #22 is the work-around ...
.. here is the current version of the proper
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-24 17:42
---
Subject: Bug 44196
Author: rguenth
Date: Mon May 24 17:41:47 2010
New Revision: 159789
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159789
Log:
2010-05-24 Richard Guenther rguent...@suse.de
PR
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-05-24 17:52
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-24 17:55 ---
Well - GCC has fallback expansions for some sign-related instructions by doing
bit-fiddling instead. I think that's whats required if the arch cannot do
a IEEE negate.
--
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-05-24 18:02
---
Thanks. With the preprocessed source I can confirm the crash and also confirm
that the fix I just committed fixes the crash.
Snapshots are generated every week, so the next is due on May 29th.
--
rguenth at
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-05-24
18:11 ---
Subject: Re: Multiplying -1 by NaN is not valid.
On Mon, 24 May 2010, rguenth at gcc dot gnu dot org wrote:
Well - GCC has fallback expansions for some sign-related instructions by doing
bit-fiddling
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-24 18:24 ---
Most likely the same issue as 20357.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from jason at gcc dot gnu dot org 2010-05-24 18:38 ---
Subject: Bug 41510
Author: jason
Date: Mon May 24 18:38:16 2010
New Revision: 159792
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159792
Log:
PR c++/41510
* decl.c (check_initializer): Don't
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-24 19:22 ---
this has nothing to do with tls it is a general issue with ObjC/lto.. :
the following code (OK w.out, error with -flto)
===
cat trivial.m:
extern int printf (char *,...) ;
typedef struct objc_class *Class;
--- Comment #10 from jan dot kratochvil at redhat dot com 2010-05-24 19:49
---
GDB counterpart (no patch now):
http://sourceware.org/bugzilla/show_bug.cgi?id=11631
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
--- Comment #4 from jan dot kratochvil at redhat dot com 2010-05-24 19:53
---
Archer counterpart (no patch now):
http://sourceware.org/bugzilla/show_bug.cgi?id=11632
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42801
--- Comment #3 from astrange at ithinksw dot com 2010-05-24 20:01 ---
Fixed itself. Though lto still doesn't build ffmpeg, it's just a different bug
now.
--
astrange at ithinksw dot com changed:
What|Removed |Added
--- Comment #24 from iains at gcc dot gnu dot org 2010-05-24 20:11 ---
Created an attachment (id=20738)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20738action=view)
candidate solution (with all the files)
and now with all the changed files ...
--
iains at gcc dot gnu dot
--- Comment #8 from jason at gcc dot gnu dot org 2010-05-24 20:33 ---
Fixed for 4.5.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2010-05-24 20:33 ---
Subject: Bug 41510
Author: jason
Date: Mon May 24 20:33:06 2010
New Revision: 159796
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159796
Log:
PR c++/41510
* decl.c (check_initializer): Don't
This function generates the following asm under -O3 in version 4.5
#include stdarg.h
void va_overload2(int p1, int p2);
void va_overload3(int p1, int p2, int p3);
void va_overload(int p1, int p2, ...)
{
if (p2 == 7)
{
va_list v;
va_start(v, p2);
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2010-05-24 21:43
---
Subject: Bug 38394
Author: ebotcazou
Date: Mon May 24 21:43:31 2010
New Revision: 159798
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159798
Log:
PR ada/38394
* gnat.dg/array13.ad[sb]:
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-05-24 21:46
---
Subject: Bug 38394
Author: ebotcazou
Date: Mon May 24 21:46:05 2010
New Revision: 159799
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159799
Log:
PR ada/38394
* gnat.dg/array13.ad[sb]:
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-24 21:47
---
Can you please provide a shorter, self-contained (no includes), testcase?
Thanks in advance. CC-ing Ian...
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2010-05-24 21:49
---
Too delicate to fix on the older branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-05-24 22:03
---
Subject: Bug 44100
Author: ebotcazou
Date: Mon May 24 22:03:09 2010
New Revision: 159800
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159800
Log:
PR middle-end/44100
* typeck.c
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-05-24 22:05
---
Should work again.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
The C++ compiler now accepts the following constructs (parse/array-size2.C):
struct S
{
char a[4];
int b;
};
extern void bar (char *, char *);
void
foo (void)
{
char g[(char *) ((struct S *) 0)-b - (char *) 0];
char h[(__SIZE_TYPE__) ((struct S *) 8)-b];
bar (g, h);
}
like the C
--- Comment #6 from mikpe at it dot uu dot se 2010-05-24 22:24 ---
The stage 3 comparison failure on ARM is as follows:
...
Bootstrap comparison failure!
libiberty/pic/cp-demangle.o differs
Comparing the disassembly listings of prev-libiberty/pic/cp-demangle.o and
The following valid code snippet triggers an ICE on the 4.5 branch
when compiled and linked with -flto -g:
=
namespace N
{
struct A {};
}
struct B
{
virtual void foo(N::A) {}
};
int main()
{
B b;
return 0;
}
=
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.1
Version|4.6.0 |4.5.1
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-24 22:41 ---
This sounds like the same as PR 44256 which was just fixed today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44264
--- Comment #8 from spop at gcc dot gnu dot org 2010-05-24 22:44 ---
-fgraphite-identity does iteration splitting for this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43423
--- Comment #9 from changpeng dot fang at amd dot com 2010-05-24 22:47
---
(In reply to comment #8)
-fgraphite-identity does iteration splitting for this case.
Do you know why it could not be vectorized after iteration
range splitting?
--
--- Comment #10 from spop at gcc dot gnu dot org 2010-05-24 23:02 ---
note: not vectorized: number of iterations cannot be computed.
Graphite has a problem with the generation of induction variables types
that makes the code harder to analyze after Graphite. I will try to get this
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-24 23:37 ---
To fix PR 23616 fully this bug needs to be fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #49 from mrs at gcc dot gnu dot org 2010-05-25 00:29 ---
r159527 has yet more lto work in it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43729
--- Comment #2 from mrs at gcc dot gnu dot org 2010-05-25 01:00 ---
Subject: Bug 43689
Author: mrs
Date: Tue May 25 01:00:16 2010
New Revision: 159805
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159805
Log:
2010-05-24 Iain Sandoe ia...@gcc.gnu.org
PR ObjC++/43689
--- Comment #3 from mrs at gcc dot gnu dot org 2010-05-25 01:02 ---
Fixed now.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
The following program compiles successfully, but results in an undefined
reference to `___MOD_names' during linking. It compiles and links successfully
with g95 0.92! (May 31, 2009)and ifort 11.1.065.
Using gfortran built from svn trunk revision 159797. Command line was simply
gfortran
--- Comment #2 from carrot at google dot com 2010-05-25 02:28 ---
Fixed by http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00860.html.
Ramana, could you help to verify and close it?
thanks
Carrot
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44227
A function that makes no other calls besides calls to __tls_get_addr does not
allocate a stack frame with a parameter save area. According to the PowerPC64
ABI, any function that makes calls must allocate at least a 112 byte stack
frame. This testcase, extracted from libstdc++
/* -m64 -fPIC -O2
--
amodra at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
g++ fails to overlook template instantiation errors involving down static_casts
over virtual inheritance boundaries. Example:
struct B {};
struct D : B {};
struct VD : virtual B {};
template class T T create();
typedef char one[1];
typedef char two[2];
template class D, class B
one f(char
94 matches
Mail list logo
