On 06/10/2010 06:28 AM, Jeremy Kerr wrote:
Hi Paolo,
The hash would be different for git diff and svn diff due to the
different headers.
The headers are not included in the hash. However, the filenames will need to
be the same - patchwork expects '-p1' patches, but normalises the top-level
per http://gcc.gnu.org/install/finalinstall.html
Built/installed 4.5 on alpha-dec-osf.
alphaev67-dec-osf5.1
bash-4.1$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper
Target: alphaev67-dec-osf5.1
Configured with:
I get an internal compiler error with gcc-4.2.1 and my own back-end
when I support conditional execution:
../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c
bug.c: In function ‘cond_assign_les0’:
bug.c:13: internal compiler error: in elim_reg_cond, at flow.c:3486
The test C file bug.c is:
int
Coo - C, Object Oriented
http://sourceforge.net/projects/coo/
-coo.h--
#ifndef __COO_H__
#define __COO_H__
typedef struct VTable /*root of virtual table class*/
{
long offset; /*servers for FREE*/
} VTable;
#define EXTENDS(s) \
union \
{ \
s s; \
-Original Message-
From: Cary Coutant [mailto:ccout...@google.com]
Sent: 09 June 2010 18:43
To: Richard Guenther
Cc: Bingfeng Mei; Jan Hubicka; gcc@gcc.gnu.org
Subject: Re: externally_visible and resoultion file
Yes, this is also what I saw without plugin. I just wonder why
Hi,
Software floating point(libgcc) routines were implemented for SH in the
following links:-
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00063.html
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00614.html
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00624.html
There were some discussions
On 06/10/2010 10:57 AM, yuanbin wrote:
initialization of the enum:
you mean union.
enum {
int i;
float f;
} t={1.5}; //t.f
The above makes no sense, what if you have int and char?
You have to say
union { ... } t = { .f = 1.5 };
and that already works in
Hi All,
I was wondering if there is any architecture which implemented complex
arithmetic in GCC i.e. used modes like CHI or HC.
I would really like to look at an example for that.
Thanks, Roy.
GNU MPFR 3.0.0 (boudin aux pommes) is now available for download
from the MPFR web site:
http://www.mpfr.org/mpfr-3.0.0/
from INRIAGForge:
https://gforge.inria.fr/projects/mpfr/
and from the GNU FTP site:
http://ftp.gnu.org/gnu/mpfr/
Thanks very much to those who sent us bug reports
Dave Korn wrote:
I've just updated my repo and will schedule a nightly build
of trunk with configure settings taken from the bundled gcc4
compiler from Cygwin pack in order to see what will happen.
That's the simplest way to guarantee compatibility.
And now the compiler works correctly, so
--
initialization of the union:
union {
int i;
float f;
} t={1.5}; //t.f
because of EXTENDS2 in coo.h, compiler needs
to initialze last member of union.
#include coo.h
typedef struct VBase {} VBase;
typedef struct CBase { VT(VBase) int i; } CBase;
typedef
initialization of global variable?
2010/6/10 Andreas Schwab sch...@redhat.com:
yuanbin yuanb...@gmail.com writes:
but i want default format:
CThis t={0, 1, 1}; //simple
Define a suitable constructor.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813
yuanbin yuanb...@gmail.com writes:
but i want default format:
CThis t={0, 1, 1}; //simple
Define a suitable constructor.
Andreas.
--
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
And now for something completely different.
Boris Boesler baem...@gmx.de writes:
I get an internal compiler error with gcc-4.2.1 and my own back-end
when I support conditional execution:
../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c
bug.c: In function ‘cond_assign_les0’:
bug.c:13: internal compiler error: in elim_reg_cond, at
Am 10.06.2010 um 15:27 schrieb Ian Lance Taylor:
Boris Boesler baem...@gmx.de writes:
I get an internal compiler error with gcc-4.2.1 and my own back-end
when I support conditional execution:
../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c
bug.c: In function ‘cond_assign_les0’:
Boris Boesler baem...@gmx.de writes:
Am 10.06.2010 um 15:27 schrieb Ian Lance Taylor:
Boris Boesler baem...@gmx.de writes:
I get an internal compiler error with gcc-4.2.1 and my own back-end
when I support conditional execution:
../build/gcc/cc1 -Wall -O1 -o bug.O1.s bug.c
bug.c: In
Amker.Cheng wrote:
Yes, I think it can be NULL in some complicated cases when a loop exit edge
comes not in the parent loop.
By that, you mean the case an regno lives on edges which transfer
between adjacent loops,
and not lives in parent loop?
Yes. But there are even more complicated
Hello again,
I have written here a few weeks ago regarding some tutorials on GCC
porting and got some very interesting replies. However, I seem to have
gotten stuck with a couple of issues in spite of my massive Googling, and
I was wondering if anyone could spare a couple of minutes for some
On Thu, Jun 10, 2010 at 2:10 PM, yuanbin yuanb...@gmail.com wrote:
initialization of global variable?
No, just define a macro.
2010/6/10 Andreas Schwab sch...@redhat.com:
yuanbin yuanb...@gmail.com writes:
but i want default format:
CThis t={0, 1, 1}; //simple
Define a suitable
Hi,
We are in the process of adding a feature to GCC to take advantage of a new
hardware feature in the latest AMD micro processor. This feature requires a
certain mix, ordering and alignments in instruction sequences to obtain the
expected hardware performance.
I am asking the community
Radu Hobincu radu.hobi...@arh.pub.ro writes:
I have written here a few weeks ago regarding some tutorials on GCC
porting and got some very interesting replies. However, I seem to have
gotten stuck with a couple of issues in spite of my massive Googling, and
I was wondering if anyone could
This compiler's extension is valuable
2010/6/10 Wojciech Meyer wojciech.me...@googlemail.com:
On Thu, Jun 10, 2010 at 2:10 PM, yuanbin yuanb...@gmail.com wrote:
initialization of global variable?
No, just define a macro.
2010/6/10 Andreas Schwab sch...@redhat.com:
yuanbin
Cross-posting Reza's call for feedback to the binutils list since it
is relevant -
see the last few paragraphs regarding how to solve the alignment problem.
Original thread: http://gcc.gnu.org/ml/gcc/2010-06/threads.html#00402
Not sure if followups should occur on one list or both.
--
Quentin
On Wed, 9 Jun 2010, Dave Korn wrote:
Here are a few of the people with access to the copyright list: me, Ian,
Benjamin Koznik, David Edelsohn, Andreas Schwab, Joseph Myers, Ralf
Wildenhues. This is not a complete list, just people that I remember.
I also have access and am happy to be asked
On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law l...@redhat.com wrote:
On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
quentin.neill@gmail.com wrote:
Cross-posting Reza's call
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
quentin.neill@gmail.com wrote:
Cross-posting Reza's call for feedback to the binutils list since it
is relevant -
see the last few paragraphs regarding how to solve the alignment problem.
Original thread:
On Tue, Jun 8, 2010 at 6:30 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 7 June 2010 22:43, Ian Lance Taylor wrote:
The patch tracker (http://gcc.gnu.org/wiki/GCC_Patch_Tracking) is not
currently operating.
Would anybody like to volunteer to get it working again?
I'm not
Quoting Jeff Law l...@redhat.com:
That adds quite a bit of complication to the compiler though -- getting
the instruction lengths right (and thus proper packing alignment) can
be extremely difficult. I did some experiments with this on a target
with *fixed* instruction lengths a while back
Hi Honza,
Here's an idea to make it easier to manually annotate
large C code bases for hot/cold functions where
it's too difficult to use profile feedback.
It's fairly common here to call function through
function pointers in manual method tables.
A lot of code is targetted by a few function
On Thu, Jun 10, 2010 at 4:08 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law l...@redhat.com wrote:
On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin
On 06/10/2010 10:37 PM, Jeff Law wrote:
Compile the attached with -O2 on x86-unknown-linux-gnu and review the
.ira dump for main()
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
Building IRA IR
starting the processing of deferred
On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
quentin.neill@gmail.com wrote:
Cross-posting Reza's call for feedback to the binutils list since it
is relevant -
see the last few paragraphs regarding how to solve the alignment problem.
Original
On 10/06/2010 18:07, yuanbin wrote:
This compiler's extension is valuable
No, it isn't very valuable, sorry to be blunt. I think you are following a
really wrong path here. You are trying to implement a C++-alike
object-oriented system in C. That makes sense as far as it goes, but if you
On Thu, Jun 10, 2010 at 3:09 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 4:08 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Jun 10, 2010 at 1:59 PM, Quentin Neill
quentin.neill@gmail.com wrote:
On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law l...@redhat.com
Compile the attached with -O2 on x86-unknown-linux-gnu and review the
.ira dump for main()
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
Building IRA IR
starting the processing of deferred insns
ending the processing of deferred insns
On Thu, Jun 10, 2010 at 3:03 PM, Jeff Law l...@redhat.com wrote:
On 06/10/10 13:52, H.J. Lu wrote:
On Thu, Jun 10, 2010 at 11:05 AM, Quentin Neill
quentin.neill@gmail.com wrote:
Cross-posting Reza's call for feedback to the binutils list since it
is relevant - s ee the last few
On Thu, Jun 10, 2010 at 02:03:03PM -0600, Jeff Law wrote:
That adds quite a bit of complication to the compiler though --
getting the instruction lengths right (and thus proper packing
alignment) can be extremely difficult. I did some experiments with
this on a target with *fixed*
Snapshot gcc-4.5-20100610 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20100610/
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/branches
typedef struct CBase { int i; } CBase;
typedef struct CT1 { EXTENDS(CBase) ... } CT1;
typedef struct CT2 { EXTENDS(CT1) ... } CT2;
...
typedef struct CTN { EXTENDS(CTN_1) ... } CTN;
CTN t;
t.i=1; //need not t.CTN_1CT2.CT1.CBase.i ---complex
CBase* p=t.CBase; //need not
On Thu, Jun 10, 2010 at 5:40 PM, Daniel Jacobowitz d...@codesourcery.com
wrote:
On Thu, Jun 10, 2010 at 02:03:03PM -0600, Jeff Law wrote:
That adds quite a bit of complication to the compiler though --
getting the instruction lengths right (and thus proper packing
alignment) can be extremely
On Fri, 2010-06-11 at 08:44 +0800, yuanbin wrote:
typedef struct CBase { int i; } CBase;
typedef struct CT1 { EXTENDS(CBase) ... } CT1;
typedef struct CT2 { EXTENDS(CT1) ... } CT2;
...
typedef struct CTN { EXTENDS(CTN_1) ... } CTN;
CTN t;
t.i=1; //need not t.CTN_1CT2.CT1.CBase.i
yuanbin yuanb...@gmail.com writes:
typedef struct CBase { int i; } CBase;
typedef struct CT1 { EXTENDS(CBase) ... } CT1;
typedef struct CT2 { EXTENDS(CT1) ... } CT2;
...
typedef struct CTN { EXTENDS(CTN_1) ... } CTN;
CTN t;
t.i=1; //need not t.CTN_1CT2.CT1.CBase.i ---complex
CBase*
--- Comment #10 from ubizjak at gmail dot com 2010-06-10 06:18 ---
(In reply to comment #9)
Following patch is also needed to fix conditional splitting (it does not fix
original uncovered problem where BLOCK_FOR_INSN returns null):
I am not sure this is correct. The code prior
--- Comment #4 from kargl at gcc dot gnu dot org 2010-06-10 06:31 ---
(In reply to comment #3)
The result of transfer is largest kind of decimal. Can be kind=8 or kind=16
depending on the system. Maybe we should add some documentation in the manual
on this. Thanks Steve for
--- Comment #17 from sebastian dot huber at embedded-brains dot de
2010-06-10 07:13 ---
Thank you for your investigations. A special case fix is better than nothing.
I am not a GCC expert but it seems that this kind of bug appears quite
regularly on different platforms and all use
--- Comment #17 from vapier at gentoo dot org 2010-06-10 07:22 ---
vanilla gcc-4.4.x shows the same behavior if you were to use the same configure
options as Gentoo. specifically, --disable-checking seems to cause this.
i dont have the ability to re-open this bug since i didnt file it
--- Comment #5 from burnus at gcc dot gnu dot org 2010-06-10 07:25 ---
I think there is another problem. Assuming the following program:
integer(4) :: i4
integer(8) :: i8
i4 = 1
i8 = transfer(i4, mold=i8)
end
The TRANSFER (as the one in comment 0) is partially undefined, but there is
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-10 07:33 ---
(In reply to comment #1)
This should work (untested). However, ASYNCHRONOUS is F2003. Should one
introduce standard-specific checks? The whole function seems to be agnostic in
this respect?!
Well, if you have
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-10 08:14
---
Thanks Jason. Actually, the issue seems already known, LWG 1326, Bullet 4 of
the proposed resolution (the name of the issue isn't particularly telling, I
would say). It's still [New] But I guess we had better
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-10 08:16
---
Sorry, I meant Bullet 5.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44487
Based on
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/377859ecc89ea65c
For the following program, gfortran just prints:
During initialization
Error: Incompatible types in DATA statement at (1); attempted conversion of
INTEGER(16) to CHARACTER(1)
Expected: gfortran
--- Comment #76 from iains at gcc dot gnu dot org 2010-06-10 09:02 ---
committed to the 4.5 branch as r160526.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
--- Comment #44 from harry dot he at freescale dot com 2010-06-10 09:03
---
Thanks for your reminding, Mark.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-10 09:18 ---
I've found now that the runtime is picked up from the install location.
For default configuration, I use --prefix=/user/inria , and the file is
then picked up from
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-06-10 09:28 ---
(In reply to comment #4)
I've found now that the runtime is picked up from the install location.
P.S.: That doesn't happen when I cut paste the LD_LIBRARY_PATH settings
and the compile command from the log file -
struct T { const char *p; };
struct S { T a, b, c; unsigned d; };
void bar (const T , const T );
void
foo (S s, T e)
{
const char *a = e.p;
const char *b = s.b.p;
__asm__ volatile (/* %0 %1 */ : : rm (a), rm (b));
bar (e, s.b);
}
has PRE_MODIFY and PRE_INC in MEM operands of
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-10 09:33 ---
I had saw this before and it was declared this was correct behavior but I
cannot find the bug any more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-06-10 09:41 ---
Found the bug which I was talking about, PR 33932.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44461
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-10 09:44 ---
struct T { unsigned long p; };
struct S { T a, b, c; unsigned d; };
__attribute__((noinline))
void
bar (const T x, const T y)
{
if (x.p != 0x2348 || y.p != 0x2346)
__builtin_abort ();
}
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-06-10 09:47 ---
I think the real issue is that m is too generic from the point of the
documentation.
Reading:
http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Simple-Constraints.html#Simple-Constraints
Makes it sound like it could
On powerpc-linux and i686-linux cxg1004 fails, here is the powerpc-linux log:
BUILD cxg1004.adb
gnatmake --GCC=/home/guerby/build/gcc/xgcc -B/home/guerby/build/gcc/ -gnatws
-O2 -I/home/guerby/build/gcc/testsuite/ada/acats/support cxg1004.adb -largs
--GCC=/home/guerby/build/gcc/xgcc
--- Comment #1 from laurent at guerby dot net 2010-06-10 09:56 ---
From the ChangeLog this patch looks like a good candidate:
+2010-06-01 Jan Hubicka j...@suse.cz
+
+ * tree-cfgcleanup.c (fixup_noreturn_call): Break out from ...;
+ remove return value.
--
laurent at
--
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=44484
--- Comment #4 from schwab at linux-m68k dot org 2010-06-10 10:12 ---
You need to use the %U and %X modifiers together with m. If the insn does
not support them (no update and/or indexed form) you cannot use m. Basically
this means you can use m only with the normal load/store insns.
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-10 10:25 ---
And ensure that it is used exactly once in an inline asm pattern? Even for g
constraint? That just can't be true.
Just look at how many of m and =m constraints e.g. glibc uses.
Only 8 occurrences of %U, but e.g.:
--- Comment #7 from paolo at gcc dot gnu dot org 2010-06-10 10:25 ---
Subject: Bug 44487
Author: paolo
Date: Thu Jun 10 10:24:46 2010
New Revision: 160528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160528
Log:
2010-06-10 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #8 from paolo at gcc dot gnu dot org 2010-06-10 10:26 ---
Subject: Bug 44487
Author: paolo
Date: Thu Jun 10 10:26:14 2010
New Revision: 160529
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160529
Log:
2010-06-10 Paolo Carlini paolo.carl...@oracle.com
PR
--- Comment #9 from paolo dot carlini at oracle dot com 2010-06-10 10:29
---
Fixed for 4.5.1.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from schwab at linux-m68k dot org 2010-06-10 10:59 ---
You can use them as many times as needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #7 from schwab at linux-m68k dot org 2010-06-10 11:06 ---
A matched constraint can never have side effects, and the powerpc specific uses
are already correct (though they could take advantage of the es or Z
constraints).
--
--- Comment #3 from hp at gcc dot gnu dot org 2010-06-10 11:11 ---
*** This bug has been marked as a duplicate of 44460 ***
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from hp at gcc dot gnu dot org 2010-06-10 11:11 ---
*** Bug 44453 has been marked as a duplicate of this bug. ***
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from hp at gcc dot gnu dot org 2010-06-10 11:13 ---
Committed.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #11 from hp at gcc dot gnu dot org 2010-06-10 11:13 ---
Subject: Bug 44460
Author: hp
Date: Thu Jun 10 11:12:12 2010
New Revision: 160533
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160533
Log:
PR rtl-optimization/44460
* emit-rtl.c
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-10 11:36 ---
Don't understand the last comment.
If matched constraint can't have side-effects, then this bug is valid and
auto-inc-dec.c should just do if (asm_noperands (insn) = 0) continue;
similarly how it refuses to auto-inc
--- Comment #9 from schwab at linux-m68k dot org 2010-06-10 11:50 ---
You cannot use an m operand more than once, since it can include side
effects.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #10 from fche at redhat dot com 2010-06-10 12:11 ---
(In reply to comment #9)
You cannot use an m operand more than once, since it can include side
effects.
Nor less than once, apparently.
--
fche at redhat dot com changed:
What|Removed
--- Comment #1 from andi-gcc at firstfloor dot org 2010-06-10 12:22 ---
I noticed that setting -fwhole-program on both compile and link stage
makes the weak problem go away. Expected?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44463
--- Comment #11 from jakub at gcc dot gnu dot org 2010-06-10 12:24 ---
I believe for GCC it shouldn't be hard to at least easily detect the used zero
times case which happens very often in lost of code.
asm (... %2 ... : =m (*p) : m (*p), r (p));
is just very common, the =m and m just
--- Comment #12 from matz at gcc dot gnu dot org 2010-06-10 12:26 ---
I don't think it ever was intended that 'm' includes operands with embedded
side-effects. I don't think so because making this work reliably is
relatively difficult. In particular the tests that Jakub mentions would
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-10 12:29 ---
(In reply to comment #1)
I noticed that setting -fwhole-program on both compile and link stage
makes the weak problem go away. Expected?
No. -fwhole-program is ignored during compile stage if -flto or -fwhopr
is
--- Comment #15 from iains at gcc dot gnu dot org 2010-06-10 12:33 ---
back-ported to 4.5 release branch as r160541.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32052
--- Comment #13 from schwab at linux-m68k dot org 2010-06-10 12:39 ---
m is defined to be the most general memory constraint, and a pre/post
modified memory operand is still a memory operand.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #14 from schwab at linux-m68k dot org 2010-06-10 12:42 ---
asm (... %2 ... : =m (*p) : m (*p), r (p));
In this case the compiler should never use a side effect.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #15 from schwab at linux-m68k dot org 2010-06-10 12:46 ---
The %X modifier has nothing to do with side effects, it is used for indexed
addressing modes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44492
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-10 12:47
---
Patch submitted at: http://gcc.gnu.org/ml/fortran/2010-06/msg00091.html
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-10 12:58 ---
On the link stage it's apparently not ignored and it fixes the weak
problem.
So just whatever weak magic -fwhole-program does would need to be done
when it's not enabled too.
--
--- Comment #8 from sandra at codesourcery dot com 2010-06-10 13:01 ---
I was barking up the wrong tree with my last idea -- the signed/unsigned
conversion business was a red herring. Here's what I now believe is the
problem: the costs computation is underestimating the register
--- Comment #10 from iains at gcc dot gnu dot org 2010-06-10 13:04 ---
back-ported to 4.5. release branch as r160546.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35996
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-10 13:20
---
I reduced another of my ICEs from this build and it's in the same place.
(gdb) bt
#0 var_map_base_init (map=0x10abe60) at ../../gcc/gcc/tree-ssa-live.c:87
#1 0x007248fb in coalesce_ssa_name () at
--- Comment #17 from andi-gcc at firstfloor dot org 2010-06-10 13:21
---
Created an attachment (id=20882)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20882action=view)
other test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #16 from fche at redhat dot com 2010-06-10 13:24 ---
(In reply to comment #13)
m is defined to be the most general memory constraint, and a pre/post
modified memory operand is still a memory operand.
If this is to stand, please amend the documentation to warn about this.
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-10 13:35
---
Still looking for feedback from the port maintainer... Suresh, the next issue
you are having should be reported separately, it's a compiler proper issue,
being an internal compiler error.
--
paolo dot
--- Comment #22 from paolo dot carlini at oracle dot com 2010-06-10 13:38
---
Jon, I would recommend closing this. We don't want to fiddle with auto_ptr
anyway, and the small issue with shared_ptr is fixed for 4.6.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
--- Comment #17 from matz at gcc dot gnu dot org 2010-06-10 13:34 ---
m is defined to be the most general memory constraint, and a pre/post
modified memory operand is still a memory operand.
I know that this is the case, which is why I said: If that means to slightly
change the
--- Comment #23 from redi at gcc dot gnu dot org 2010-06-10 13:54 ---
we have regressed in terms of the warning, but no diagnostic is required and
auto_ptr is deprecated in C++0x, so WONTFIX
--
redi at gcc dot gnu dot org changed:
What|Removed
--- Comment #11 from paolo dot carlini at oracle dot com 2010-06-10 14:07
---
I'm tempted to commit Suresh patch, properly tweaked for the copyright years,
in mainline and close the PR: I think it's short enough to not require a full
assignment, and we can certainly improve the
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-10 14:30
---
(In reply to comment #10)
(In reply to comment #9)
Following patch is also needed to fix conditional splitting (it does not
fix
original uncovered problem where BLOCK_FOR_INSN returns null):
I am
--- Comment #4 from domob at gcc dot gnu dot org 2010-06-10 14:48 ---
Subject: Bug 38936
Author: domob
Date: Thu Jun 10 14:47:49 2010
New Revision: 160550
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160550
Log:
2010-06-10 Daniel Kraft d...@domob.eu
PR fortran/38936
--- Comment #12 from paolo at gcc dot gnu dot org 2010-06-10 14:53 ---
Subject: Bug 43918
Author: paolo
Date: Thu Jun 10 14:53:15 2010
New Revision: 160551
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160551
Log:
2010-06-10 Suresh Gumpula suresh.gump...@amd.com
PR
1 - 100 of 178 matches
Mail list logo
