On 8 June 2010 05:42, Basile Starynkevitch wrote:
On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
On 06/07/10 14:31, Ian Lance Taylor wrote:
The gcc project currently has a problem: when people who are not
regular gcc developers send in a patch, those patches often get
dropped. They
Hi all,
I've committed the gc-improv code to trunk. The testsuite is still
running, however bootstrap went fine on x86_64/linux. Due to nature of
the changes, any problems should show up as bootstrap compile errors
and on x86_64/linux I don't expect them.
The problems are more (although IMHO not
Reading gcc-cvs, or ChangeLogs, or other things like that is just way
too much time.
What about writing a small script that parses the main ChangeLogs? They are
supposed to be uniformly formatted. And ping messages shouldn't contain all
the junk of previous messages, just the ChangeLog (and
On 06/08/2010 06:42 AM, Basile Starynkevitch wrote:
On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
So perhaps the thing to do is somehow separate patches from regular
contributors and irregular contributors. A relatively easy way to do
this would be for a regular contributor to include a
On 8 June 2010 07:43, Chiheng Xu chiheng...@gmail.com wrote:
On Tue, Jun 8, 2010 at 9:14 AM, Ben White ja_wal...@sbcglobal.net wrote:
Would a modestly modified copy of Bugzilla be workable for that something?
I.E. Patchzilla?
Think about mercurial or git. Every one can commit on his/her own
On 8 June 2010 10:43, Paolo Bonzini bonz...@gnu.org wrote:
On 06/08/2010 06:42 AM, Basile Starynkevitch wrote:
On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
So perhaps the thing to do is somehow separate patches from regular
contributors and irregular contributors. A relatively easy
On 8 June 2010 11:17, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
On 8 June 2010 10:43, Paolo Bonzini bonz...@gnu.org wrote:
On 06/08/2010 06:42 AM, Basile Starynkevitch wrote:
On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
So perhaps the thing to do is somehow separate patches from
Hi,
We have been implementing GCC port for a new target.
The FRAME_POINTER_REGNUM is defined a pseudo register in header file.
I am using the following macros in header file to eliminate the pseudo
arg pointer and frame pointer.
However, there are some instances of frame pointer in the assembly
On x86_64/linux, the merge does not cause any new testsuite
regressions, except the fact that two new testcases were added during
the freeze:
gfortran.dg/proc_ptr_27.f90
g++.dg/cpp0x/decltype23.C
So now I am more or less done with testing, and I am waiting for any
complaints :)
--
Laurynas
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 volunteering, but I might look into it one day. I already
have too little spare time for
Hi,
Sorry for coming back to this issue after a while. I am still puzzled
by this. The following are two test files:
a.c
#include string.h
#include stdio.h
extern int foo(int);
void bar()
{
printf(bar\n);
}
extern int src[], dst[];
int vv;
int main()
{
int ret;
vv = 12;
ret
On Tue, Jun 8, 2010 at 3:01 PM, Bingfeng Mei b...@broadcom.com wrote:
Hi,
Sorry for coming back to this issue after a while. I am still puzzled
by this. The following are two test files:
a.c
#include string.h
#include stdio.h
extern int foo(int);
void bar()
{
printf(bar\n);
}
extern
I'm currently working on an update of the patch for PR42843, and I wonder
what best to do about the symbol plugin_is_GPL_compatible.
Although gcc doesn't currently mangle global variables, a future version of
gcc - or any other build compiler - might add mangling.
If I add:
#ifdef __cplusplus
On Tue, Jun 08, 2010 at 09:48:15AM -0400, Joern Rennecke wrote:
I'm currently working on an update of the patch for PR42843, and I wonder
what best to do about the symbol plugin_is_GPL_compatible.
extern int plugin_is_GPL_compatible;
However, it would mean that plugin_is_GPL_compatible
Thanks. But why v is linked correctly here? Shouldn't it
be treated as static with -fwhole-program?
Bingfeng
-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com]
Sent: 08 June 2010 14:10
To: Bingfeng Mei
Cc: Jan Hubicka; gcc@gcc.gnu.org; Cary Coutant
On Tue, Jun 8, 2010 at 4:15 PM, Bingfeng Mei b...@broadcom.com wrote:
Thanks. But why v is linked correctly here? Shouldn't it
be treated as static with -fwhole-program?
Works for me without the linker plugin as well:
gcc-4.5 -O2 -o t t1.o t2.o -flto -fwhole-program -B
Quoting Laurynas Biveinis laurynas.bivei...@gmail.com:
I forgot in my previous e-mail the actual diff and the ChangeLogs of
the gc-improv merge, attaching now.
Your gcc/gcc/cp/ChangeLog entry starts with 'Likewise.'
Yes, this is also what I saw without plugin. I just wonder why v
is linked with plugin if resolution file is not used to eliminate need
of externally_visible attribute here.
Thanks,
Bingfeng
-Original Message-
From: Richard Guenther [mailto:richard.guent...@gmail.com]
Sent: 08
On Tue, Jun 8, 2010 at 4:22 PM, Bingfeng Mei b...@broadcom.com wrote:
Yes, this is also what I saw without plugin. I just wonder why v
is linked with plugin if resolution file is not used to eliminate need
of externally_visible attribute here.
Probably because of the same linker-plugin bug
On Tue, Jun 8, 2010 at 3:53 AM, Eric Botcazou ebotca...@adacore.com wrote:
Reading gcc-cvs, or ChangeLogs, or other things like that is just way
too much time.
What about writing a small script that parses the main ChangeLogs? They are
supposed to be uniformly formatted. And ping messages
Joern Rennecke wrote:
#ifdef __cplusplus
extern C {
#endif
extern int plugin_is_GPL_compatible;
#ifdef __cplusplus
}
#endif
I think that's a good idea; I don't think that at this point we've made
any plugin compatibility guarantees. (In the future, I think we should
-- but only when we
On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlini paolo.carl...@oracle.com wrote:
On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote:
Perhaps NightStrike can fine-tune his approach.
By the way, I wonder how many contributors can even think taking
seriously a message coming from NightStrike. Not me,
2010/6/8 Joern Rennecke amyl...@spamcop.net:
Quoting Laurynas Biveinis laurynas.bivei...@gmail.com:
I forgot in my previous e-mail the actual diff and the ChangeLogs of
the gc-improv merge, attaching now.
Your gcc/gcc/cp/ChangeLog entry starts with 'Likewise.'
I have noticed it before the
I first installed gcc 4.5.0 on my Powerpc dual 970 machine with no
configuration options. That was successful, but the long long feature was
not enabled. Then I re-installed gcc 4.5.0 with this gcc v output:
Using built-in specs.
COLLECT_GCC=gcc
On 06/08/10 09:01, NightStrike wrote:
On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlinipaolo.carl...@oracle.com wrote:
On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote:
Perhaps NightStrike can fine-tune his approach.
By the way, I wonder how many contributors can even think
Hi all,
Jeremy has set up a Patchwork instance for us at
http://patchwork.ozlabs.org/project/gcc/list/ .
It is feeding from gcc-patches; the plan is to make it
automatically recognise what patches went into the tree,
probably by snooping the gcc-cvs list.
You can also manually change patch
On Tue, Jun 8, 2010 at 11:21 AM, Jeff Law l...@redhat.com wrote:
On 06/08/10 09:01, NightStrike wrote:
On Mon, Jun 7, 2010 at 8:34 PM, Paolo Carlinipaolo.carl...@oracle.com
wrote:
On 06/08/2010 02:20 AM, Manuel López-Ibáńez wrote:
Perhaps NightStrike can fine-tune his approach.
By
On Mon, Jun 7, 2010 at 10:43 PM, Chiheng Xu chiheng...@gmail.com wrote:
On Tue, Jun 8, 2010 at 9:14 AM, Ben White ja_wal...@sbcglobal.net wrote:
Would a modestly modified copy of Bugzilla be workable for that something?
I.E. Patchzilla?
Think about mercurial or git. Every one can commit on
On 8 June 2010 17:42, H.J. Lu hjl.to...@gmail.com wrote:
git is an excellent tool to create and share patches. Maybe we should
have an open gcc git mirror with gitweb and every contributor can create
his/her own branches and publish them.
http://gcc.gnu.org/wiki/GitMirror
I don't see how
Hi,
I am forwarding to you a mail that I sent to the uClibc mailing list as
I think it is actually a compiler issue. Please see below for the
original. Any tips would be greatly appreciated.
/Jonas
Forwarded Message
From: jonas at southpole dot se
To: ucl...@uclibc.org
On 06/08/2010 05:42 PM, H.J. Lu wrote:
Think about mercurial or git. Every one can commit on his/her own
local repository, and publish his/her repository. [...]
git is an excellent tool to create and share patches. Maybe we should
have an open gcc git mirror with gitweb and every
Are you volunteering to write that small script?
If nothing better comes out, why not, but resurrecting the Patch Tracker seems
to be a more appealing idea.
--
Eric Botcazou
On Tue, 2010-06-08 at 09:21 -0600, Jeff Law wrote:
Look, you don't want me to be here... fine. I get it. Enough is
enough already. Technical disagreements are one thing. Personal
attacks on me are just juvenile.
I don't see this as a personal attack.
Like Paolo, I'm a lot
On 06/08/2010 08:40 PM, Basile Starynkevitch wrote:
There is no personal attack involved.
For sure. Sorry if my quick remark could be interpreted in another way.
Paolo.
On Tue, 2010-06-08 at 11:18 +0200, Manuel López-Ibáñez wrote:
I don't understand. WAA rights definitely allow you to shepherd and commit
patches from people without svn access, even for patches you can't approve.
And basile (and other WAA contributors), this would a nice
contribution.
On 06/08/2010 09:21 PM, Basile Starynkevitch wrote:
On Tue, 2010-06-08 at 11:18 +0200, Manuel López-Ibáñez wrote:
I don't understand. WAA rights definitely allow you to shepherd and commit
patches from people without svn access, even for patches you can't approve.
And basile (and other WAA
Naveen H. S navee...@kpitcummins.com writes:
The FRAME_POINTER_REGNUM is defined a pseudo register in header file.
I am using the following macros in header file to eliminate the pseudo
arg pointer and frame pointer.
However, there are some instances of frame pointer in the assembly code.
Segher Boessenkool seg...@kernel.crashing.org writes:
Jeremy has set up a Patchwork instance for us at
http://patchwork.ozlabs.org/project/gcc/list/ .
It is feeding from gcc-patches; the plan is to make it
automatically recognise what patches went into the tree,
probably by snooping the
Jonas Bonn jo...@southpole.se writes:
I am forwarding to you a mail that I sent to the uClibc mailing list as
I think it is actually a compiler issue. Please see below for the
original. Any tips would be greatly appreciated.
This message would be more appropriate for the mailing list
It is feeding from gcc-patches; the plan is to make it
automatically recognise what patches went into the tree,
probably by snooping the gcc-cvs list.
This is quite interesting, thanks for setting it up.
All kudos go to Jeremy, I merely try to push people :-)
I can see already that to be
On 08/06/2010 20:31, Paolo Bonzini 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
Snapshot gcc-4.4-20100608 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100608/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 6/8/10, NightStrike nightstr...@gmail.com wrote:
Are you volunteering to write that small script?
DUnno, are you volunteering to write that small script?
You're the only one here actually volunteering a forwardgoing
commitment of their time here to improve GCC's development in this
way, it
Hi Ian,
I can see already that to be useful for gcc today it will need some
curating. E.g., http://patchwork.ozlabs.org/patch/54974/ is both 1)
committed; 2) on a branch. This one
http://patchwork.ozlabs.org/patch/54958/ is committed to trunk.
There are a number of ways to keep the patch
On Tue, Jun 8, 2010 at 11:55 PM, Tobias Burnus bur...@net-b.de wrote:
On 06/08/2010 05:42 PM, H.J. Lu wrote:
Think about mercurial or git. Every one can commit on his/her own
local repository, and publish his/her repository. [...]
git is an excellent tool to create and share patches. Maybe
On Tue, Jun 8, 2010 at 7:03 PM, Martin Guy martinw...@gmail.com wrote:
On 6/8/10, NightStrike nightstr...@gmail.com wrote:
Are you volunteering to write that small script?
DUnno, are you volunteering to write that small script?
Sorry, no :(
You're the only one here actually volunteering a
--- Comment #4 from fm3 at os dot inf dot tu-dresden dot de 2010-06-08
06:19 ---
Yes, you are right. This is a duplicate. Thanks.
--
fm3 at os dot inf dot tu-dresden dot de changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-08 06:37 ---
Subject: Bug 6
Author: burnus
Date: Tue Jun 8 06:37:32 2010
New Revision: 160424
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160424
Log:
2010-06-07 Tobias Burnus bur...@net-b.de
PR
--- Comment #33 from Kyle dot D dot Moffett at boeing dot com 2010-06-08
06:48 ---
EGLIBC and PPL are still building; I'm heading to sleep and I'll check on them
later this morning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-08 07:02 ---
(In reply to comment #1)
Untested:
And not working ;-)
Anyway, the bug is now FIXED on the trunk (4.6). Thanks for the report!
--
burnus at gcc dot gnu dot org changed:
What|Removed
For the following testcase:
__attribute__ ((noinline,noclone))
int
i_am_pure (int a)
{
if (a10)
abort();
}
main()
{
int a = i_am_pure (5) + i_am_pure (5);
int b = i_am_pure (8) + i_am_pure (8);
return a;
}
We get only one call to i_am_pure optimized out:
main ()
{
int a;
int
--- Comment #2 from mikpe at it dot uu dot se 2010-06-08 08:19 ---
The same error occurs for java on ARM, see PR44335. I posted a patch to fix
that one (must include both tm.h and tm_p.h in jcf-parse.c) that but so far has
gotten no response to it.
--
mikpe at it dot uu dot se
--- Comment #3 from doko at ubuntu dot com 2010-06-08 08:35 ---
proposed patch at
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00658.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
Hit this while attempting to compile a large code base with WHOPR:
tweak1.c:
void y(void) { printf(y\n); }
void x(void) __attribute__((weak, alias(y)));
tweak2.c:
void x(void) { printf(strong\n); }
tweak3.c:
extern void x(void);
int main(void) { x(); return 0; }
Compile with
gcc -fwhopr
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-08 08:49 ---
Hm? The return values are removed as part of first DCE pass.
bb 2:
D.2721_1 = i_am_pure (5);
D.2722_2 = i_am_pure (5);
a_3 = D.2721_1 + D.2722_2;
i_am_pure (8);
i_am_pure (8);
return a_3;
and FRE/PRE
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Summary|r160380 breaks libjava |[4.6 Regression] r160380
|bootstrap on
--- Comment #1 from ubizjak at gmail dot com 2010-06-08 08:50 ---
FAIL: g++.dg/torture/pr32304.C -O3 -g (internal compiler error)
also fails with the same ICE on x86_64-pc-linux-gnu [1].
[1] http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00759.html
--
ubizjak at gmail dot com
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-08 08:51 ---
By switching the GCC build language to C++, we introduce name mangling,
which means that we loose plugin dynamic link compatibility to previous
versions of gcc. Also, the interface becomes subject to change when
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-08 08:53 ---
Created an attachment (id=20864)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20864action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44460
--
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=44454
--
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=44453
--- Comment #5 from iains at gcc dot gnu dot org 2010-06-08 08:55 ---
this has been fixed for some time in the test-suite by running only for
*-*-darwin* and skipping for gnu-runtime.
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
I got several ICEs during a linux kernel whopr build, here's one of them.
gcc46 -nostdlib -fwhopr -r -o net/ipv4/built-in.o net/ipv4/route.o
net/ipv4/inetpeer.o net/ipv4/protocol.o net/ipv4/ip_input.o
net/ipv4/ip_fragment.o net/ipv4/ip_forward.o net/ipv4/ip_options.o
net/ipv4/ip_output.o
--- Comment #9 from pluto at agmk dot net 2010-06-08 09:07 ---
(In reply to comment #8)
(In reply to comment #5)
have a look at PR44406... i believe its the same thing.
I think it probably is because the patch of mine would lead to code
very similar to what exposed PR
--- Comment #1 from andi-gcc at firstfloor dot org 2010-06-08 09:38 ---
Ok unable to attach and I've been told reporting LTO bugs requires some magic
voodoo incarnations first.
If it helps here's the gdb information of the crash:
(gdb) pt var
error_mark 0x1200022
(gdb) bt
#0
--- Comment #2 from andi-gcc at firstfloor dot org 2010-06-08 09:40 ---
The object files are at http://halobates.de/whopr-ice.tar.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-08 09:55 ---
Did you reduce the number of object files already? Note that you are linking
without optimization (and you probably built the .o files with optimization?)
So this might be a duplicate of PR41159.
Can you put
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-08 09:56 ---
(In reply to comment #2)
By switching the GCC build language to C++, we introduce name mangling,
which means that we loose plugin dynamic link compatibility to previous
versions of gcc. Also, the interface
We are developing object oriented examples for our next book and have hit a
compiler bug with the following short program.
program polymorphic
use shape_module
use circle_module
use rectangle_module
implicit none
type shape_w
class (shape_type) , allocatable :: shape_v
end type shape_w
--- Comment #10 from pluto at agmk dot net 2010-06-08 10:15 ---
the gcc-4.5-20100608 still miscompiles kde4libs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
--- Comment #4 from kasparek at fit dot vutbr dot cz 2010-06-08 10:34
---
Hello, is there any progress in this, may I help with something?
--
kasparek at fit dot vutbr dot cz changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-08 10:35 ---
Needs '-g -O1' to fails:
[macbook] i386/libjava% /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc
-nostdinc++ -DHAVE_CONFIG_H -I. -I../../../../work/libjava -I./include -I./gcj
-I../../../../work/libjava -Iinclude
When doing (node_refine.i attached):
gcc -DNDEBUG -O3 -I. -c node_refine.i
I get:
node_refine.c: In function KWayNodeRefine__:
node_refine.c:162:6: internal compiler error: Violació de segment
Please submit a full bug report,
with preprocessed source if appropriate.
See
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-08 10:37 ---
pr44460 is probably a duplicate. The test fails with -g -O1 and the backtrace
is
#0 fancy_abort (file=0x100ad07d0 ../../work/gcc/emit-rtl.c, line=1674,
function=0x100b42a40 set_mem_attributes_minus_bitpos) at
--- Comment #1 from msteghofer at cistib dot upf dot edu 2010-06-08 10:38
---
Created an attachment (id=20865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20865action=view)
The code that produces the error
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44466
--- Comment #2 from msteghofer at cistib dot upf dot edu 2010-06-08 10:38
---
GCC version info:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/data/home/msteghofer/gcc-4.5/dist/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2010-06-08 10:41
---
Elimination of subsequent calculations of PIC addresses should be handled in
code hoisting optimization.
However, there are two problems that inhibit the optimization:
1. ARM backend outputs calculation of a
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-08 11:11 ---
This has been fixed for 4.5.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from gcc at breakpoint dot cc 2010-06-08 11:23 ---
(In reply to comment #28)
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
(TARGET_E500_DOUBLE ((MODE) == VOIDmode || (MODE) == DFmode) \
? DFmode
With revision 160368 the tree built.
From revision 160380 and on including at least 160431, build has failed as
follows:
libtool: compile: /tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-shared-libgcc -B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc -nostdinc++
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-08 12:40 ---
This is the patch set for the fix:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00741.html
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00740.html
--
amylaar at gcc dot gnu dot org changed:
What
--- Comment #1 from hp at gcc dot gnu dot org 2010-06-08 12:43 ---
Created an attachment (id=20866)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20866action=view)
preprocessed
cc1plus -fpreprocessed eh_alloc.ii -melf -quiet -dumpbase eh_alloc.cc
-auxbase-strip eh_alloc.o -g -O2
#include stddef.h
struct S {
int i;
int j;
};
struct R {
int k;
struct S a;
};
struct Q {
float k;
struct S a;
};
struct Q s;
int __attribute__((noinline,noclone))
test1 (void *q)
{
struct S *b = (struct S *)((char *)q + sizeof (int));
s.a.i = 0;
b-i = 3;
return s.a.i;
}
int
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-08 12:52 ---
Argument why the testcase is invalid might go along the line that a pointer
to struct Q may not be converted to a pointer to struct R, or that
((struct R *)q)-a is accessing *q as struct R.
This is similar to
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-08 12:53 ---
Fixed on the mem-ref branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44468
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-08 12:57 ---
*** Bug 44467 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-08 12:57 ---
*** This bug has been marked as a duplicate of 44460 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-08 12:58 ---
Likely pr44453 and pr44460.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44467
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-08 13:00 ---
(In reply to comment #0)
c:\document\fortran\newbook\examples\ch32gfortran shape_p.f90 circle_p.f90
rectangle_p.f90 polymorph_array.f90
polymorph_array.f90: In function 'polymorphic':
polymorph_array.f90:18:0:
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-08 13:03 ---
Subject: Bug 44468
Author: rguenth
Date: Tue Jun 8 13:02:53 2010
New Revision: 160435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160435
Log:
2010-06-08 Richard Guenther rguent...@suse.de
--- Comment #4 from jamborm at gcc dot gnu dot org 2010-06-08 13:16 ---
Mine
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #2 from ian at rhymneyconsulting dot co dot uk 2010-06-08
13:21 ---
Subject: RE: [OOP] ICE with polymorphic object oriented example
I should have included them with the bug report!
Things are really progressing with the compiler.
Well done!
Out of the compilers Jane and
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-08 13:53 ---
Valgrind shows:
==26969== Invalid read of size 4
==26969==at 0x553131: gfc_conv_scalarized_array_ref (trans-array.c:2494)
==26969==by 0x553824: gfc_conv_array_ref (trans-array.c:2547)
==26969==by
--- Comment #5 from martin at mpa-garching dot mpg dot de 2010-06-08 13:54
---
(In reply to comment #2)
We have (4.4):
bb 2:
va.f[0] = a-r;
va.f[1] = a-g;
va.f[2] = a-b;
va.f[3] = 0.0;
pretmp.40 = va.v;
ivtmp.61 = 0;
[...]
Could you please tell me the compiler
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-08 14:02 ---
(In reply to comment #5)
(In reply to comment #2)
We have (4.4):
bb 2:
va.f[0] = a-r;
va.f[1] = a-g;
va.f[2] = a-b;
va.f[3] = 0.0;
pretmp.40 = va.v;
ivtmp.61 = 0;
[...]
Could
--- Comment #17 from sfilippone at uniroma2 dot it 2010-06-08 14:09 ---
(In reply to comment #16)
(In reply to comment #14)
The attached variation of generic_23 still does not work.
[sfili...@donald bug15]$ ./generic_23_1
FOO%DOIT base version
Aborted (core dumped)
(In
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-08 14:22 ---
Actually this seems to be a duplicate of PR 44211. It is fixed by the patch I
submitted yesterday:
http://gcc.gnu.org/ml/fortran/2010-06/msg00060.html
The patch has been approved by Tobias, and I will commit it once
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-08 14:22 ---
*** Bug 44465 has been marked as a duplicate of this bug. ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jay dot foad at gmail dot com 2010-06-08 14:24 ---
I've just seen this too:
$ gcc --version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
[...]
$ cat a.h
void a(void);
$ cat b.h
#include a.h
$ cat b.c
#include b.h
void b(void) {}
$ gcc -c -g3 a.h
$ gcc -c -g3 b.c
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-06-08 14:29 ---
I don't think I can fix this bug in its most general form without
doing some flow-sensitive decisions (which can be difficult for
aggregates) and without causing PR 43846 again. (Aggregate
copy-propagation and
1 - 100 of 160 matches
Mail list logo
