On 05/18/2010 04:24 AM, Sandeep Soni wrote:
On Tue, May 18, 2010 at 2:34 AM, Andrew Haley a...@redhat.com wrote:
For example:
A textual GIMPLE tuple for the statement a=b+c can be like
GIMPLE_ASSIGNPLUS_EXPR,a,b,c (As demonstrated by the internal
manual also).
Is such a
Hi,
I have for call_value a define_expand and define_insn that look like:
(define_expand call_value
[
(set (match_operand 0 )
(call (match_operand:QI 1 nonmemory_operand )
(match_operand:QI 2 immediate_operand )))
]
)
(define_insn *call_value
[
(set
On Mon, May 17, 2010 at 16:15, Sandeep Soni soni.sande...@gmail.com wrote:
1. What should be the format of representation of the GIMPLE tuples in text?
I liked Andrew's suggestion about S-expressions. It looks like a good
balance between ease of parsing/writing. We can always tweak the
format
[ hmf. This one got lost to an smtp error when I sent it yesterday. It
appears there's more or less agreement that at the moment you're supposed to
manually annotate all external entry points if you want to use -fwhole-program
on a library. On windows, where we often do that anyway, it looks
Hi,
On Tue, 18 May 2010, Diego Novillo wrote:
On Mon, May 17, 2010 at 16:15, Sandeep Soni soni.sande...@gmail.com wrote:
1. What should be the format of representation of the GIMPLE tuples in
text?
I liked Andrew's suggestion about S-expressions.
I can see that for describing
On 18/05/2010 13:01, Paulo J. Matos wrote:
I have for call_value a define_expand and define_insn that look like:
(define_expand call_value
[
(set (match_operand 0 )
(call (match_operand:QI 1 nonmemory_operand )
(match_operand:QI 2 immediate_operand )))
]
On Tue, May 18, 2010 at 09:59, Michael Matz m...@suse.de wrote:
I don't see how that is much easier to parse compared to
i_1 = k_1 + m_1
j_1 = func (arg1, arg2)
Well, it would make the parser almost trivial to implement. But you
have a point, the only structurally complex objects we need
[ hmf. This one got lost to an smtp error when I sent it yesterday. It
appears there's more or less agreement that at the moment you're supposed to
manually annotate all external entry points if you want to use -fwhole-program
on a library. On windows, where we often do that anyway, it
On Tue, May 18, 2010 at 4:09 PM, Diego Novillo dnovi...@google.com wrote:
On Tue, May 18, 2010 at 09:59, Michael Matz m...@suse.de wrote:
I don't see how that is much easier to parse compared to
i_1 = k_1 + m_1
j_1 = func (arg1, arg2)
Well, it would make the parser almost trivial to
On Tue, May 18, 2010 at 3:26 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
This however causes an unrecognizable insn error during the compiler
runtime when I have TARGET_X defined.
I was expecting the clobbers not to influence the recognition but it
seems I was wrong.
Actually, IIUC the
On Tue, 2010-05-18 at 15:59 +0200, Michael Matz wrote:
Hi,
On Tue, 18 May 2010, Diego Novillo wrote:
On Mon, May 17, 2010 at 16:15, Sandeep Soni soni.sande...@gmail.com wrote:
1. What should be the format of representation of the GIMPLE tuples in
text?
I liked Andrew's
On Tue, May 18, 2010 at 4:30 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
On Tue, 2010-05-18 at 15:59 +0200, Michael Matz wrote:
Hi,
On Tue, 18 May 2010, Diego Novillo wrote:
On Mon, May 17, 2010 at 16:15, Sandeep Soni soni.sande...@gmail.com
wrote:
1. What should be the
On 18/05/2010 15:24, Paulo J. Matos wrote:
On Tue, May 18, 2010 at 3:26 PM, Dave Korn dave.korn.cyg...@gmail.com wrote:
This however causes an unrecognizable insn error during the compiler
runtime when I have TARGET_X defined.
I was expecting the clobbers not to influence the recognition but
On 18/05/2010 15:17, Steven Bosscher wrote:
IMHO, ideally we would have a syntax that is human readable and human
writable. S-expressions are not as easy to read for me as something
that resembles C.
I'd like it that way too, but I acknowledge that it would be more work and
it's not me
On Tue, May 18, 2010 at 4:30 PM, Basile Starynkevitch
bas...@starynkevitch.net wrote:
BTW, is it possible today to have a GCC plugin providing a front-end to
GCC? [last time I looked, I believe the answer is no]
This is one of the reasons for my patches to better hide the
middle-end details
On 05/18/2010 04:05 PM, Dave Korn wrote:
On 18/05/2010 15:17, Steven Bosscher wrote:
IMHO, ideally we would have a syntax that is human readable and human
writable. S-expressions are not as easy to read for me as something
that resembles C.
I'd like it that way too, but I acknowledge
[ apologies for the duplicate message. My previous reply was bounced
by the ML. ]
On Tue, May 18, 2010 at 10:52, Andrew Haley a...@redhat.com wrote:
On 05/18/2010 04:05 PM, Dave Korn wrote:
On 18/05/2010 15:17, Steven Bosscher wrote:
IMHO, ideally we would have a syntax that is human
On Tue, May 18, 2010 at 8:33 PM, Diego Novillo dnovi...@google.com wrote:
Yup. This shade of blue can be changed later. Sandi, let's start
with the S-expression syntax for everything. Richard is correct in
pointing out that even gimple expressions have metadata associated
with them that
Hi,
Is it possible to update the multilib combinations supported by GCC after it
has been built? (I would like to build some libraries optimised for
different CPUs variants, that aren't built by default).
I tried doing this via a specs file, but something like the following fails:
%rename
On Tue, 2010-05-18 at 18:30 +0100, Jon Beniston wrote:
Is it possible to update the multilib combinations supported by GCC after it
has been built?
I don't know for sure, but I would guess and imagine that it is not
possible. The intuition is that multilib-ness is really a matter of
choosing
Jon Beniston j...@beniston.com writes:
Is it possible to update the multilib combinations supported by GCC after it
has been built?
I believe that all the multilib information can be read from the specs
file, so, technically, yes.
%rename multilib_matches old_multilib_matches
I have a case where I think useless stores are being generated, but I
want to be sure before I file a bug. This is with gcc 4.4.3 on Ubuntu
10.04, x86-64.
I have been experimenting with returning structs from functions instead
of passing pointers to out parameters. This seems like it should be
How do i build gcc for linux?
On 05/18/2010 01:11 PM, packet wrote:
How do i build gcc for linux?
Oh the irony of the subject.
This is better asked on the gcc-help mailing list.
--
Joel Sherrill, Ph.D. Director of Research Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me
On Tue, 18 May 2010, Jon Beniston wrote:
Hi,
Is it possible to update the multilib combinations supported by GCC after it
has been built? (I would like to build some libraries optimised for
different CPUs variants, that aren't built by default).
I tried doing this via a specs file, but
Hi all,
how can I disallow the mov operation for a register class.
Can someone help me?
Thanks,
Egge
Hi,
A couple of days ago i was asking:
does any frontend support some sort of noting that a user-header was
included but no decl of it was ever referenced (i.e. superfluous
#include) ?
I could not find an appropriate tool to diagnose them, so i was thinking
about a gcc plugin to do that.
Would
On 5/18/10, Bernhard Reutner-Fischer rep.dot@gmail.com wrote:
Hi,
A couple of days ago i was asking:
does any frontend support some sort of noting that a user-header was
included but no decl of it was ever referenced (i.e. superfluous
#include) ?
I could not find an appropriate tool to
Snapshot gcc-4.4-20100518 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100518/
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 05/18/2010 05:53 PM, Steven Bosscher wrote:
On 5/18/10, Bernhard Reutner-Fischerrep.dot@gmail.com wrote:
Hi,
A couple of days ago i was asking:
does any frontend support some sort of noting that a user-header was
included but no decl of it was ever referenced (i.e. superfluous
Joshua Haberman jhaber...@gmail.com writes:
I have a case where I think useless stores are being generated, but I
want to be sure before I file a bug. This is with gcc 4.4.3 on Ubuntu
10.04, x86-64.
I concur that this is a missed optimization bug.
Ian
Eggenmüller Bernd egg...@gmx.de writes:
how can I disallow the mov operation for a register class.
Can someone help me?
Please do not start a new thread by replying to an existing message.
That hides your message for all of us who use threaded e-mail readers.
If there is some mode which can
Ian Lance Taylor iant at google.com writes:
Joshua Haberman jhaberman at gmail.com writes:
I have a case where I think useless stores are being generated, but I
want to be sure before I file a bug. This is with gcc 4.4.3 on Ubuntu
10.04, x86-64.
I concur that this is a missed
Several people have asked that there be a forum for asking questions of
and providing feedback to the GCC RMs. Since this is of course a very
widely distributed community, the best medium for this seems to be an
IRC chat. To that end, I'll be hosting a 1-hour session on May 27th at
9:00 AM
On Tue, May 18, 2010 at 11:36 PM, Mark Mitchell m...@codesourcery.com wrote:
Several people have asked that there be a forum for asking questions of
and providing feedback to the GCC RMs. Since this is of course a very
widely distributed community, the best medium for this seems to be an
IRC
NightStrike wrote:
If anyone would like to volunteer to set up a channel and/or moderate
the chat itself, please let me know.
Can you just do it in #gcc on oftc?
That's certainly the fallback possibility. Though, for those not
interested, it would interrupt whatever else is being
I'm writing to report a discrepancy in
http://gcc.gnu.org/install/prerequisites.html
I just discovered that if gmp is boot strapped during gcc build and an older m4
exists, when gmp calls flex, it will fail during configure with:
checking for flex... flex
checking lex output file root...
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 ---
*** Bug 44187 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-05-18 06:31 ---
*** This bug has been marked as a duplicate of 44186 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ethouris at gmail dot com 2010-05-18 07:14 ---
No matter which entity is actually affected in the example above, 'foo' is a
type of field used inside the entity. In all these cases, deprecation warning
should not be reported for the field of type 'foo'. It should be
--- Comment #1 from hjl dot tools at gmail dot com 2010-05-18 07:29 ---
In general, with inlining, not a huge deal, although it can still
occur when functons are short-circuited. For certain applicatons
that are built with PIC, the IP-thunk, at the very least, should
be padded since
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-05-18 07:41
---
I need the preprocessed file. Thanks in advance.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #4 from segher at gcc dot gnu dot org 2010-05-18 08:26 ---
Confirmed with current 4.4 branch and mainline.
-mabi=nospe -mno=spe doesn't make the problem go away; only
changing -mcpu does.
--
segher at gcc dot gnu dot org changed:
What|Removed
--- Comment #17 from iains at gcc dot gnu dot org 2010-05-18 09:09 ---
Created an attachment (id=20693)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693action=view)
latest version
a few more tweaks.
with this emutls is working for lto/whopr
OMP is still broken and so will be
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-18 09:25
---
Note however, that both the warning and the miscompilation do not happen with
current 4_5-branch and mainline...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
typedef struct
{
int i;
} AAA;
typedef struct BBB
{
int i;
} BBB;
int main(void) {
BBB bb;
AAA aa;
return 0;
}
produces
3a2: Abbrev Number: 9 (DW_TAG_variable)
a3 DW_AT_name: bb
a6 DW_AT_decl_file : 1
a7
--- Comment #27 from jakub at gcc dot gnu dot org 2010-05-18 09:36 ---
Subject: Bug 41371
Author: jakub
Date: Tue May 18 09:35:52 2010
New Revision: 159528
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159528
Log:
PR debug/41371
* var-tracking.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-05-18 09:53 ---
(In reply to comment #3)
Note however, that both the warning and the miscompilation do not happen with
current 4_5-branch and mainline...
Which is because we see the must-alias and punt. After all this just
--
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=44185
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-18 10:04 ---
Confirmed. Assembly with 4.4 is equal -g vs. -g0 and different starting with
4.5.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|x86_64-pc-linux-gnu |
GCC host triplet|x86_64-pc-linux-gnu |
GCC target
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-18 10:08
---
Ok ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44186
--- Comment #28 from siarhei dot siamashka at gmail dot com 2010-05-18
10:09 ---
Thanks, this patch fixes bootstrap for powerpc/powerpc64. But still fails for
arm on all the same gcc_assert() in another place. Should a new bug be filed
about this?
--
--- Comment #16 from fxcoudert at gcc dot gnu dot org 2010-05-18 10:28
---
Confirmed on gcc version 4.5.1 20100506 (prerelease).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2010-05-18 10:35
---
Doesn't happen for me with the 4.5 branch. (I don't have a current trunk
compiler to compare with.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43821
--- Comment #9 from sfilippone at uniroma2 dot it 2010-05-18 10:41 ---
(In reply to comment #8)
(In reply to comment #7)
Btw, after the recent patch for PR43969, this might well be fixed already ...
Unfortunately, no, I still get the ICE.
--
--- Comment #29 from jakub at gcc dot gnu dot org 2010-05-18 10:58 ---
Please file a new PR for that, with preprocessed source and all other relevant
info for reproduction.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42347
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-18 11:26 ---
The differences start during inlining.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44182
SVN revision: 159525
Configure line: ../gcc-svn/configure --prefix=/tmp/gcc-cross/gcc-svn-bin/
--target=arm-linux-gnueabi
--with-headers=/tmp/gcc-cross/gcc-svn-bin/arm-linux-gnueabi/include
--with-libs=/tmp/gcc-cross/gcc-svn-bin/arm-linux-gnueabi/lib/
--enable-threads=posix --enable-shared
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-18 11:55 ---
Created an attachment (id=20694)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20694action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44101
--- Comment #10 from janus at gcc dot gnu dot org 2010-05-18 12:19 ---
(In reply to comment #9)
Btw, after the recent patch for PR43969, this might well be fixed already
...
Unfortunately, no, I still get the ICE.
Sure. Actually my comment was only targeted towards Tobias'
--- Comment #11 from burnus at gcc dot gnu dot org 2010-05-18 12:24 ---
(In reply to comment #8)
If one adds b = ALLOCATED(x) one finds:
Where do you add this?
Add in bug14 of attachment 20491 before 'end subroutine':
logical b
b = allocated(a%a)
However, this is now fixed.
*
--- Comment #3 from iains at gcc dot gnu dot org 2010-05-18 12:30 ---
it still fails for me on ppc and i686 4.6.0 r159518 and 159528 resp.
gcc version 4.5.1 20100518 (prerelease) [gcc-4_5-branch revision 159528] (GCC)
apollo:gcc-4-5-branch-build $ ./gcc/xgcc -B gcc -g -feliminate
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-18 13:04 ---
I guess this is related to the EH rewrite in 4.5.
In particular, when building cfg for f2 in make_blocks on
(gdb) p debug_gimple_stmt (stmt)
S::f3 (this, D.2140);
(gdb) p stmt_can_throw_internal (stmt)
$47 = 0 '\000'
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-18 13:52 ---
Subject: Bug 44184
Author: steven
Date: Tue May 18 13:51:50 2010
New Revision: 159531
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159531
Log:
gcc/
PR lto/44184
* lto-streamer-out.c
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-18 14:07 ---
Subject: Bug 44184
Author: steven
Date: Tue May 18 14:06:31 2010
New Revision: 159532
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159532
Log:
gcc/
PR lto/44184
* lto-streamer-out.c
--- Comment #3 from steven at gcc dot gnu dot org 2010-05-18 14:08 ---
Fixed for GCC 4.5.1 and later.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from ktietz at gcc dot gnu dot org 2010-05-18 14:22 ---
(In reply to comment #10)
Re-opening. It turns out that GCC fails to actually apply the dllexport
attribute to TLS control vars. So solving the binutils problem allows
auto-export of a TLS variable to work, but
--- Comment #12 from davek at gcc dot gnu dot org 2010-05-18 14:29 ---
(In reply to comment #11)
I have doubts about the approach in winnt.c, but well maybe I am wrong here. I
investigated for this issue and see the real issue in declaration cloning in
varasm.c's emutls_decl-
--- Comment #13 from davek at gcc dot gnu dot org 2010-05-18 14:33 ---
(In reply to comment #12)
TARGET_EMUTLS_VAR_INIT
Nah, scratch that, it's not really sensible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #10 from rguenth at gcc dot gnu dot org 2010-05-18 14:58
---
(In reply to comment #9)
But the standard says in [basic.types] that For any trivially copyable type
T,
if two pointers to T point to distinct T objects obj1 and obj2, where neither
obj1 nor obj2 is a
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-05-18 15:00
---
(In reply to comment #10)
(In reply to comment #9)
But the standard says in [basic.types] that For any trivially copyable
type T,
if two pointers to T point to distinct T objects obj1 and obj2, where
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-05-18 15:02
---
Making this a C++ frontend bug. The only way to avoid expanding the copy
to a loop is by using memcpy which will then run into PR42834.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-05-18 15:11 ---
Subject: Bug 44143
Author: rguenth
Date: Tue May 18 15:11:01 2010
New Revision: 159536
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159536
Log:
2010-05-18 Richard Guenther rguent...@suse.de
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-05-18 15:11 ---
Fixed again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ktietz at gcc dot gnu dot org 2010-05-18 15:18 ---
Hi Dave,
following patch solves the issue for me pretty well.
ChangeLog
* varasm.c (emutls_decl): Clone attributes for new decl.
Index: gcc/gcc/varasm.c
--- Comment #15 from davek at gcc dot gnu dot org 2010-05-18 15:26 ---
(In reply to comment #14)
Hi Dave,
following patch solves the issue for me pretty well.
That looks good to me to, although doing it in the middle-end makes me worry
that some other target might /not/ be
--- Comment #18 from iains at gcc dot gnu dot org 2010-05-18 15:55 ---
(In reply to comment #17)
Created an attachment (id=20693)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20693action=view) [edit]
latest version
a few more tweaks.
with this emutls is working for lto/whopr
--- Comment #16 from dominiq at lps dot ens dot fr 2010-05-18 16:28 ---
You may be interested by pr 44132.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139
--- Comment #19 from dominiq at lps dot ens dot fr 2010-05-18 16:55 ---
This PR may have an overlap with pr44139.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
--
ccoutant at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ccoutant at gcc dot gnu dot
|dot org
--- Comment #1 from vmakarov at redhat dot com 2010-05-18 19:06 ---
It will be fixed by IRA without cover classes which I am working on. The code
is planned to be included in gcc4.6.
For older versions, it should be fixed in reload because I believe it is a
hidden reload bug.
--
--- Comment #1 from gergely+gccbug at risko dot hu 2010-05-18 19:17 ---
Added wrong-debug as a keyword.
--
gergely+gccbug at risko dot hu changed:
What|Removed |Added
--- Comment #2 from ro at gcc dot gnu dot org 2010-05-18 19:39 ---
This happens on i386-pc-solaris2.11, too, but only with -flto and -fwhopr.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from changpeng dot fang at amd dot com 2010-05-18 19:39
---
I have a patch to fix the test cases:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01359.html
For prefetch-6.c, patch http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg00567.html
applies the insn to prefetch ratio
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-18 19:42 ---
Ian, you've introduced this testcase; could you have a look?
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from chris dot litchfield at gmail dot com 2010-05-18
19:48 ---
This is still a huge issue. We would wish to inhibit use of the CURRENT
Working directory to find include files. Basically FORCE every time a new
include file is found with #include to start AGAIN from
--- Comment #4 from iains at gcc dot gnu dot org 2010-05-18 20:04 ---
(In reply to comment #3)
Ian, you've introduced this testcase; could you have a look?
Yes.. working my way through ..
I'm sure that it is problem with ObjC
(and ObjC++, if you apply
--- Comment #13 from pluto at agmk dot net 2010-05-18 20:57 ---
btw. the boost::optional uses char-based storage and cast storage
- void* - some_type* via address() and get_object() methods.
it looks like aliasing violation too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44164
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-18 21:17 ---
If
print *, (foo())
is changed to
print *, foo()
one gets:
$ gfortran-svn pr41859.f90
pr41859.f90:17.19:
print *, foo() ! -- ICE here!
1
Error: Data transfer element at (1) cannot
--- Comment #3 from dfranke at gcc dot gnu dot org 2010-05-18 21:30 ---
Breakpoint 9, resolve_transfer (code=0x8bfed90) at
/home/daniel/svn/gcc-svn/gcc/fortran/resolve.c:7369
(gdb) list
7367 exp = code-expr1;
7368
7369 if (exp-expr_type != EXPR_VARIABLE exp-expr_type !=
--- Comment #4 from vmakarov at redhat dot com 2010-05-18 21:40 ---
Thanks for reporting the problem. The problem has no effect on generated
code whatever initialization is used. The code in question tries to get basic
block for BARRIER which is wrong. Whatever it gets basic block
The assertion in the following testcase should /not/ fail, but does:
#define _GLIBCXX_DEBUG
#define _GLIBCXX_DEBUG_PEDANTIC
#include vector
#include cassert
int main()
{
std::vectorint v;
v.resize(10);
assert(v.size() = v.capacity());
}
--
Summary: Debug
--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net 2010-05-18
21:45 ---
Created an attachment (id=20695)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20695action=view)
Trivial patch that fixes the problem.
The problem was just a missing call to
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #13 from burnus at gcc dot gnu dot org 2010-05-18 21:51 ---
Created an attachment (id=20696)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20696action=view)
Fifth draft patch - with test case
New approach. The attached patch now also works with twisted modules (cf.
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-18 21:54 ---
Comment #3 is somewhat hard to parse. Once more with this reduced testcase:
TYPE :: ptype
character, pointer, dimension(:) :: x = null()
END TYPE
TYPE(ptype) :: p
print *, (p)! '()' are
1 - 100 of 129 matches
Mail list logo
