On Wed, Jan 06, 2010 at 04:18:06PM +0100, Jakub Jelinek wrote:
On Wed, Jan 06, 2010 at 10:15:58AM +, Andrew Haley wrote:
On 01/06/2010 09:59 AM, Mark Colby wrote:
Yabbut, how come RTL cse can handle it in x86_64, but PPC not?
Probably because the RTL on x86_64 uses and's and ior's,
On Thu, Jan 07, 2010 at 09:48:53AM +0100, Gabriel Paubert wrote:
apparently rs6000_emit_set_long_const needs work.
lis 3,0x8034
extsw 3,3
or
li 3,0x401a
sldi 3,3,17
etc. do IMHO the same.
Huh? I don't think so:
- first one loads 0x__8034_ in r3, and
I've been working on instruction scheduling issues for our (Ubicom) ISA
and have run into a problem I can't seem to resolve.
The pipeline has a major hazard associated with the generation of
addresses that are loaded from memory - the hazard window is 4
instructions. This is more than enough
On Thu, Jan 07, 2010 at 03:53:59AM -0500, Jakub Jelinek wrote:
On Thu, Jan 07, 2010 at 09:48:53AM +0100, Gabriel Paubert wrote:
apparently rs6000_emit_set_long_const needs work.
lis 3,0x8034
extsw 3,3
or
li 3,0x401a
sldi 3,3,17
etc. do IMHO the same.
Huh? I don't
Hello,
I have been trying to implement sibcalls (you can see my digression
yesterday in gcc-help) for an arch with gcc 4.3.4.
The problem with this is that I only want to sibcall when it happens
to reduce my code size.
I noticed (in the internals manual) we cannot actually fallback to a
normal
Guys,
While looking the GCC code, all the releases really from the 3.X.X
the GNU gettext/libintl lock.c,h code the GCC/libjava code, the
GCC/libgomp code, I have observed that the thread-id zero is widely
used to initialize/free recursive mutexes/monitors etc.
Eg GCC 4.X.X,
Sent from my iPhone
On Jan 7, 2010, at 1:59 AM, Takis Psarogiannakopoulos
ta...@xfree86.org wrote:
Guys,
While looking the GCC code, all the releases really from the 3.X.X
the GNU gettext/libintl lock.c,h code the GCC/libjava code, the
GCC/libgomp code, I have observed that the
On Wed, 2010-01-06 at 18:26 +, Paul Brook wrote:
On Wednesday 06 January 2010, Carrot Wei wrote:
So thumb2 can also use the instructions similar to thumb1, right? It
potentially has better performance and smaller code size.
Technically yes, however in ARMv7 the relevant instruction
On Thu, 7 Jan 2010, Andrew Pinski wrote:
As long as owner is not used when count is 0, then I don't see an
issue. Note I know libobjc does implement it incorrectly; I have not
had time to fix that.
Thanks,
Andrew Pinski
Absolutely right, unfortunately on all cases I am reffereed the
On Thursday 07 January 2010, Richard Earnshaw wrote:
On Wed, 2010-01-06 at 18:26 +, Paul Brook wrote:
On Wednesday 06 January 2010, Carrot Wei wrote:
So thumb2 can also use the instructions similar to thumb1, right? It
potentially has better performance and smaller code size.
On 01/06/2010 07:24 PM, Joshua Haberman wrote:
In the notes that Nick referenced it says:
Is there anybody that thinks the rules are clear enough? No one is
really able to interpret them. So it seems that they are not
clear enough. The problem is how to state them.
[...]
On Thu, Jan 7, 2010 at 12:29 PM, Andrew Haley a...@redhat.com wrote:
On 01/06/2010 07:24 PM, Joshua Haberman wrote:
In the notes that Nick referenced it says:
Is there anybody that thinks the rules are clear enough? No one is
really able to interpret them. So it seems that they are
Hi all,
With the code:
-
extern void display(unsigned int);
void callee(int z) // Sibcall worth it
{
display(z);
}
void caller(int x, int y) // Sibcall not worth it
{
display(x);
display(y);
callee(x*y);
}
-
I have put a
On 01/07/2010 11:42 AM, Richard Guenther wrote:
On Thu, Jan 7, 2010 at 12:29 PM, Andrew Haley a...@redhat.com wrote:
On 01/06/2010 07:24 PM, Joshua Haberman wrote:
The response I think you may get is that this is already settled.
I've seen this same argument many times (in mailing lists and
On Thu, Jan 7, 2010 at 11:46 AM, Paulo J. Matos pocma...@gmail.com wrote:
Hi all,
With the code:
-
extern void display(unsigned int);
void callee(int z) // Sibcall worth it
{
display(z);
}
void caller(int x, int y) // Sibcall not worth it
{
Paulo J. Matos wrote:
This case is interesting because it seems that callee is being inlined
into caller. Still intriguing is that the same happens with: -Os
-fno-inline -fno-inline-small-functions
-fno-inline-functions-called-once
There are loads of other inline-related -f options apart
Paulo J. Matos wrote:
The problem with this is that I only want to sibcall when it happens
to reduce my code size.
I noticed (in the internals manual) we cannot actually fallback to a
normal call once we decide to sibcall through FUNCTION_OK_FOR_SIBCALL,
however, FUNCTION_OK_FOR_SIBCALL is
On 01/06/10 12:54:21, Ian Lance Taylor wrote:
I think you need to make sure that the script removes any existing
config.cache files.
Ian, thanks. This turned out to be a cockpit error on my part.
The reghunt tools apparently expect the checked out gcc source tree
to have the form souce
Dear all,
I've gone to using unspec and I think I know why I have a problem. It
seems that actually, the problem lies with the fact that these
instructions are touching an internal register and how I am handling
that register.
Since I don't want the register allocator to use that register, I put
On 01/07/2010 01:59 AM, Takis Psarogiannakopoulos wrote:
The right thing to do is use the depth (count above) of the mutex to
decide if the mutex is free. The owner shoud be valid only if the mutex is
locked.
I believe the following should fix this for you, at least for libgomp.
If you have a
On 01/07/2010 12:58 PM, Jean Christophe Beyler wrote:
Dear all,
I've gone to using unspec and I think I know why I have a problem. It
seems that actually, the problem lies with the fact that these
instructions are touching an internal register and how I am handling
that register.
Since I don't
I am almost convinced I had tried that already but apparently not.
This seems to have fixed my problem, thank you :-)
Jc
On Thu, Jan 7, 2010 at 4:14 PM, Richard Henderson r...@redhat.com wrote:
On 01/07/2010 12:58 PM, Jean Christophe Beyler wrote:
Dear all,
I've gone to using unspec and I
Snapshot gcc-4.5-20100107 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100107/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
I believe the following should fix this for you, at least for libgomp.
If you have a system for which the thread-id 0 is actually used, would
you mind testing it?
This code is dead, it was only used for Solaris 2.5.1 and 2.6 and we don't
support these versions any longer, see config.gcc. I'd
--- Comment #22 from ubizjak at gmail dot com 2010-01-07 08:02 ---
(In reply to comment #21)
Because at the point of propagation, propagated constant _is_ equal to
whatever REG_EQUAL says. Removing this note at the point of propagation
would IMO disable much more optimization
--- Comment #12 from burnus at gcc dot gnu dot org 2010-01-07 08:10 ---
Subject: Bug 41872
Author: burnus
Date: Thu Jan 7 08:09:51 2010
New Revision: 155687
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155687
Log:
2010-01-07 Tobias Burnus bur...@net-b.de
PR
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-07 08:12 ---
Subject: Bug 42597
Author: burnus
Date: Thu Jan 7 08:12:10 2010
New Revision: 155688
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155688
Log:
2010-01-07 Tobias Burnus bur...@net-b.de
PR
--- Comment #13 from burnus at gcc dot gnu dot org 2010-01-07 08:12 ---
Hopefully, all issues are now fixed. Thus:
Mark as FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-07 08:13 ---
FIXED on the trunk (4.5).
Thanks for reporting the bug!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from ebotcazou at gcc dot gnu dot org 2010-01-07 08:22
---
I'm thinking about the same situation with cse2, where constant assignment
(with its REG_EQUAL note) would match another assignment with the same
REG_EQUAL note. cse2 can equal this other assignment (through
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pzhao at gcc dot gnu dot org
|dot org
--
pzhao at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pzhao at gcc dot gnu dot org
|dot org
--- Comment #24 from ubizjak at gmail dot com 2010-01-07 08:50 ---
(In reply to comment #23)
The proposed change removes REG_EQUAL note only on moved insn, (insn 538) in
our case.
That's too aggressive in the general case, no need to remove a REG_EQUAL note
pointing to a
--- Comment #25 from ubizjak at gmail dot com 2010-01-07 09:17 ---
New patch revision in testing:
--cut here--
Index: ifcvt.c
===
--- ifcvt.c (revision 155686)
+++ ifcvt.c (working copy)
@@ -4087,7 +4087,8 @@
--- Comment #6 from sliao at google dot com 2010-01-07 09:18 ---
For the trunk snapshot of 20100102, GCC 4.5.0 indeed removes most of the
redundancy. However, -O1 and -Os still produce an extra instruction, while -O2
doesn't. Do we care about an extra instruction below? Thanks.
The
--- Comment #26 from ubizjak at gmail dot com 2010-01-07 09:23 ---
Oops, brain dump error. This is correct:
Index: ifcvt.c
===
--- ifcvt.c (revision 155686)
+++ ifcvt.c (working copy)
@@ -4087,7 +4087,8 @@
--- Comment #7 from steven at gcc dot gnu dot org 2010-01-07 09:49 ---
*sigh* With all the Google power, why can't anyone there try to debug this?
I'll have a look.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
addl$4, %esp
popl%ebx
popl%ebp
ret
.size foo, .-foo
.ident GCC: (GNU) 4.5.0 20100107 (experimental)
.section.note.GNU-stack,,@progbits
---
$ gcc -O3 -fno-tree-dominator-opts -S foo.c
$ cat foo.s
See the attachment for the cfg pictures.
Thanks,
Eric
foo_vcg.tar
Description: Unix tar archive
--- Comment #14 from jamborm at gcc dot gnu dot org 2010-01-07 10:38
---
Subject: Bug 42157
Author: jamborm
Date: Thu Jan 7 10:38:25 2010
New Revision: 155689
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155689
Log:
2010-01-07 Martin Jambor mjam...@suse.cz
PR
--- Comment #15 from jamborm at gcc dot gnu dot org 2010-01-07 10:47
---
The patch that I finally committed is also slightly different but should avoid
this problem too.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from anton at samba dot org 2010-01-07 11:01 ---
Thanks Richard, it passes my tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42528
--- Comment #27 from ubizjak at gmail dot com 2010-01-07 11:21 ---
Patch at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00318.html .
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from sliao at google dot com 2010-01-07 11:31 ---
1. Yes, the flags used are -mthumb -Os -march=armv5te.
2. For completeness, I also tried to generate 32-bit instructions. In this case
of ARM mode, GCC 4.5.0 (trunk as of last week) didn't store things onto stack
--- Comment #3 from rearnsha at gcc dot gnu dot org 2010-01-07 11:45
---
(In reply to comment #2)
1. Yes, the flags used are -mthumb -Os -march=armv5te.
4c: e8bd41f0pop {r4, r5, r6, r7, r8, lr}
50: e12fff1ebx lr
This looks more like a return
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known to work||4.4.2
Summary|wrong code for -fgraphite- |[4.5
--- Comment #28 from debian-gcc at lists dot debian dot org 2010-01-07
11:54 ---
the bootstrap succeeds with the patch from comment #18 applied, test results at
http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg00633.html
Matthias
--
--- Comment #1 from zsojka at seznam dot cz 2010-01-07 12:43 ---
Created an attachment (id=19496)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19496action=view)
testcase (not reduced)
While reducing this testcase with delta, different -fcompare-debug problem
appeared (with
--- Comment #3 from sliao at google dot com 2010-01-07 12:43 ---
Because:
This bug can be more easily demonstrated with multiplication of tv_sec by 10
and tv_usec/ 1000 removed
, the input program is:
#include sys/time.h
extern void get_time(struct timeval*);
void test(long long
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-01-07 12:47 ---
'been looking at it a bit. It's graphite's
rewrite_commutative_reductions_out_of_ssa that removes SSA PHI nodes from the
IR without actually releasing them, so we don't get a chance to propagate the
DEFs into debug
--- Comment #3 from zsojka at seznam dot cz 2010-01-07 12:50 ---
-fno-web helps even with original testcase (and higher optimization level)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
--- Comment #4 from sliao at google dot com 2010-01-07 12:55 ---
Compilation flags: -march=armv5te -mthumb -Os
gcc.4.2.1: (code size 0x1e bytes)
push {r4, lr}
sub sp, #8
adds r4, r0, #0
mov r0, sp
bl 0 get_time
ldr r2, [sp, #0]
add sp, #8
lsls r3, r2, #2
adds r3, r3, r2
lsls
--- Comment #29 from uros at gcc dot gnu dot org 2010-01-07 13:02 ---
Subject: Bug 42511
Author: uros
Date: Thu Jan 7 13:02:34 2010
New Revision: 155691
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155691
Log:
PR target/42511
* ifcvt.c (dead_or_predicable):
Command line:
g++ -O1 -fcompare-debug -c testcase.cpp
-fno-web doesn't help
Tested revisions (x86_64):
r155680 - crash
r155662 - crash (x86)
r154886 - crash
r153685 - crash
Output:
$ /mnt/svn/gcc-trunk/binary-155680-lto/bin/g++ -O1 -fcompare-debug -c
testcase.cpp
g++: testcase.cpp:
--- Comment #1 from zsojka at seznam dot cz 2010-01-07 13:12 ---
Created an attachment (id=19497)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19497action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42645
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-01-07 13:15 ---
Mine
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from sliao at google dot com 2010-01-07 13:28 ---
Using flags, -march=armv5te -mthumb -Os, GCC 4.5.0 (trunk) generates the
following code:
test:
0:b570 push{r4, r5, r6, lr}
2:b084 subsp, #16
4:1c05 adds
--- Comment #4 from debian-gcc at lists dot debian dot org 2010-01-07
13:53 ---
a build with BOOT_CFLAGS set to -g -O1 succeeds
Matthias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42509
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-01-07 13:53 ---
Yeah, it surprised me a bit too, but now that I looked into it I see it makes
perfect sense. There was a PHI node before the debug stmt that expanded into
this debug insn. The variable is indeed live at that
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-07 14:13 ---
I can reproduce the problem with the testcase and the patch seems to fix it
(with the typo fixed and as far as you can test for fixed random behavior...).
I'm going to bootstrap, test and install it.
--
rguenth
--- Comment #3 from baldrick at gcc dot gnu dot org 2010-01-07 14:22
---
I added version.h to the list of installed headers in commit 155692.
--
baldrick at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from jlpoole at pon dot net 2010-01-07 14:26 ---
Success.
There were no further responses to my question posed in Comment #10; so I
proceeded nonetheless.
I deleted /usr/local/gcj and recreated the directory /usr/local/gcj so as to
purge any hand-added files from
callfun_2
cmpl$9, %ebx
jle .L5
addl$4, %esp
popl%ebx
popl%ebp
ret
.size foo, .-foo
.ident GCC: (GNU) 4.5.0 20100107 (experimental)
.section.note.GNU-stack,,@progbits
--- Comment #1 from joefoxreal at gmail dot com 2010-01-07 14:29 ---
Created an attachment (id=19498)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19498action=view)
cfg of the function foo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42646
--- Comment #10 from drow at gcc dot gnu dot org 2010-01-07 14:42 ---
Ramana, is this fixed or are you planning on applying it to more branches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
--- Comment #30 from rguenth at gcc dot gnu dot org 2010-01-07 14:44
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42536
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-07 14:47 ---
I wonder if the C++ FE should diagnose this as invalid anyway?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2010-01-07 14:49 ---
I had better add this to the list!
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-07 14:50 ---
Does the ICE happen with the stage1 compiler? Thus, is this PR maybe related
to PR42511?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42619
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42625
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-07 14:54 ---
We have to rule out miscompilation of stage3 here. Does the error reproduce
if you configure with --disable-bootstrap or just use CLFAGS=-g -O3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42628
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42631
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42637
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42644
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-01-07 14:58 ---
Works with a cross from i?86-linux, so I suspect prev-gcc is miscompiled.
Please
check if the issue remains with PR42511 fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42619
--- Comment #31 from uros at gcc dot gnu dot org 2010-01-07 15:00 ---
Subject: Bug 42511
Author: uros
Date: Thu Jan 7 14:59:59 2010
New Revision: 155693
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155693
Log:
* ifcvt.c (if_convert): Output slim multiple dumps with
--- Comment #11 from ramana at gcc dot gnu dot org 2010-01-07 15:03 ---
(In reply to comment #10)
Ramana, is this fixed or are you planning on applying it to more branches?
This is fixed on trunk. I plan to put this on 4.4 branch but it won't be before
the end of the week that I can
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-07 15:10 ---
Subject: Bug 42625
Author: jakub
Date: Thu Jan 7 15:10:26 2010
New Revision: 155694
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155694
Log:
PR tree-optimization/42625
* cgraph.c
--- Comment #7 from martin at mpa-garching dot mpg dot de 2010-01-07 15:16
---
Created an attachment (id=19499)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19499action=view)
Proposed wwwdocs patch to explain the apparent performance regression
Here is a proposed patch to
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-01-07 15:27 ---
Can you please post the patch to gcc-patc...@gcc.gnu.org instead? Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42376
--- Comment #4 from ramana at gcc dot gnu dot org 2010-01-07 15:57 ---
I don't see these failures in recent testresults on gcc-testresults. For
instance look at :
http://gcc.gnu.org/ml/gcc-testresults/2009-12/msg02629.html
Hence closing this out.
--
ramana at gcc dot gnu dot org
Follow up to PR 41872.
The following program shows at run time:
Fortran runtime error: Attempting to allocate already allocated array 'a'
type t
! Any scalar/array allocatable component will do for the wrong-code
integer, allocatable :: d
end type
type(t), allocatable :: a
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-07 16:07 ---
Subject: Bug 42641
Author: rguenth
Date: Thu Jan 7 16:07:17 2010
New Revision: 155695
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155695
Log:
2010-01-07 Richard Guenther rguent...@suse.de
PR
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-07 16:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2010-01-07 16:35 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
I thought we only had XPASSes.
XPASS: gcc.dg/guality/pr41353-1.c -O0 line 28 j == 28 + 37
FAIL: gcc.dg/guality/pr41353-1.c -O1 line 28 i1 == 2 * 37
FAIL: gcc.dg/guality/pr41353-1.c -O1 line 28 i2 == 3 * 37
FAIL: gcc.dg/guality/pr41353-1.c -O2 line 28 i1 == 2 * 37
FAIL:
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-07 16:42
---
Ok, let's re-open this and add the basic implementation in time for gcc4.5
(C++0x mode only of course).
--
paolo dot carlini at oracle dot com changed:
What|Removed
--
Summary: Optimizer breaks boost shared_ptr
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy:
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #1 from rlogel at navtech dot aero 2010-01-07 16:46 ---
Created an attachment (id=19500)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19500action=view)
Shared Pointer Test Program
This test program shows that the shared_ptr reference counter isn't being
incremented
The one of following valid Fortran 90 functions is rejected: While the first
function func works and has function name = result name, the second
(func2), which uses RESULT(), is rejected with the error message:
Error: The type for function 'func2' at (1) is not accessible
type(t) function
--- Comment #2 from rlogel at navtech dot aero 2010-01-07 16:49 ---
# Vaild Excutable
g++ -v -save-temps -o shared_ptr_test.exc shared_ptr_test.cpp
# Invalid Excutable
g++ -v -save-temps -O2 -o shared_ptr_test.exc shared_ptr_test.cpp
GCC output:
$ g++ -v -save-temps -O2 -o
--- Comment #3 from rlogel at navtech dot aero 2010-01-07 16:50 ---
Boost web page show that they tested 3.4.3 without any problems.
--
rlogel at navtech dot aero changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-07 16:52
---
3.4.6?!? Please, try current, maintained, releases, gcc4.3.x or, better,
gcc4.4.x, and in case open an appropriate PR. Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #5 from rlogel at navtech dot aero 2010-01-07 16:56 ---
I realize that 3.4.6 is very old, but we need to support RedHat Enterprise 4
builds which use gcc 3.4.6. We would rather not undertake upgrading to gcc 4.x
because we have a large legacy code base, some of which uses
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-07 17:02
---
Yes, but it's totally unmaintained, I'm sorry, we don't get PRs for
unmaintained branches, that's the policy.
--
paolo dot carlini at oracle dot com changed:
What|Removed
Sent from my iPhone
On Jan 7, 2010, at 8:56 AM, rlogel at navtech dot aero gcc-bugzi...@gcc.gnu.org
wrote:
--- Comment #5 from rlogel at navtech dot aero 2010-01-07 16:56
---
I realize that 3.4.6 is very old, but we need to support RedHat
Enterprise 4
builds which use gcc
1 - 100 of 193 matches
Mail list logo
