Re: [RFC] Migrate pointers to members to the middle end
On 8/8/07, Daniel Berlin [EMAIL PROTECTED] wrote:
I also haven't necessarily said what Ollie has proposed is a bad idea.
I have simply said the way he has come up with what he proposed is
not the way we should go about this. It may turn out he has come up
with exactly the representation we want (though I doubt this, for
various reasons).The specification given also doesn't even explain
where/how these operations can occur in GIMPLE, and what they do other
than a C++ something something.
Also given that someone already wrote a type-based devirtualizer that
worked fine, and i don't see how a points-to one is much work, I'd
like to see more justification for things like PTRMEM_PLUS_EXPR than
hey, the C++ FE generates this internally.
OK. It sounds like I need to go into a lot more detail. The new
nodes I've proposed aren't actually motivated by the C++ front end,
but rather by a consideration of the semantics dictated by the C++
standard. Naturally, this gives rise to some similarity, but for
instance, there is no PTRMEM_PLUS_EXPR in the C++ front end, and my
definition of PTRMEM_CST disagrees with the current node of the same
name.
Let's walk through them:
PTRMEM_TYPE
Contains the types of the member (TREE_TYPE) and class
(TYPE_PTRMEM_BASETYPE) of this pointer to member. This is hopefully
self-explanatory. In the language of the C++ standard, it is the type
of a pointer to member of class TYPE_PTRMEM_BASETYPE of type
TREE_TYPE. This is the type of PTRMEM_CST's, PTRMEM_PLUS_EXPR's, and
various variable types (VAR_DECL, FIELD_DECL, PARM_DECL, etc.).
PTRMEM_CST
The C++ front end already has a PTRMEM_CST node. However, the
existing node only contains a class (PTRMEM_CST_CLASS) and member
(PTRMEM_CST_MEMBER), and is unable to represent an arbitrary pointer
to member value. This is especially evident when dealing with
multiple inheritance. Consider the following example:
struct B { int f (); };
struct L : B {};
struct R : B {};;
struct D : L, R {};
int (B::*pb)() = B::f;
int (L::*pl)() = pb;
int (R::*pr)() = pb;
int (D::*pd[2])() = { pl, pr };
In this case, pd[0] and pd[1] both have the same type and point to the
same member of the same class (B::f), but they point to different base
class instances of B. To represent this, we need an offset. Now, one
might argue that rather than a numeric offset, we should point to the
_DECL of the base class subobject, but that breaks down because the
following is also legal:
struct B {};
struct D : B { int f (); };
int (D::*pd)() = D::f;
int (B::*pb)() = static_castint (B::*)()(pd);
In this case, pb points to D::f in the derived class. Since there is
no subobject to point to, we see that a numeric offset representation
is required.
This leads to the definition of PTRMEM_CST which I have adopted.
Since the class type is already provided in its type, we store the
member (TREE_PTRMEM_CST_MEMBER) and numeric offset
(TREE_PTRMEM_CST_OFFSET). The member is one of NULL (for NULL
pointers to members), a FIELD_DECL (for non-NULL pointers to data
members), or a FUNCTION_DECL (for non-NULL pointers to member
functions). I've chosen the offset value according to convenience.
For NULL pointers to members, it's irrelevant. For pointers to data
members, it's the offset of the member relative to the current class
(as determined by any type conversions). For pointers to member
functions, it's the offset to the this pointer which must be passed to
the function.
PTRMEM_PLUS_EXPR
From the discussion above, it's clear that type conversions on
pointers to members require adjustments to the offsets (to fields or
this pointers). We could handle this via CONVERT_EXPRs, but that has
two shortcomings: (1) it requires the middle end to compute offsets to
base class subobjects, and (2) as the first code example above
illustrates, multiple CONVERT_EXPRs cannot be folded together. To
work around these issues, I've implemented the PTRMEM_PLUS_EXPR. It's
a binary expression which takes two arguments, a PTRMEM_TYPE object,
and an integral offset expression. These can be nicely constant
folded, either with other PTRMEM_PLUS_EXPRs or with PTRMEM_CSTs.
There's also an added benefit when dealing with NULL pointers to
members. Consider the following code:
struct B { int a; };
struct L : B {};
struct R : B {};;
struct D : L, R {};
int B::*pb = NULL;
int L::*pl = pb;
int R::*pr = pb;
int D::*pd[2] = { pl, pr };
The C++ standard states that pd[0] == pd[1] since all NULL pointers to
members of the same type compare equal. However, the current GCC
implementation gets this wrong because the C++ front end implements
pointer to data member via simple addition. In practice, it needs to
check for NULL first. However, folding stacked conversions then
requires optimizing code like:
if (d != NULL_MARKER) d += offset1;
if (d != NULL_MARKER) d += offset2;
if (d != NULL_MARKER) d += offset3;
to
if (d!= NULL_MARKER) d +=
Re: [RFC] Migrate pointers to members to the middle end
On 8/8/07, Ollie Wild [EMAIL PROTECTED] wrote:
On 8/8/07, Daniel Berlin [EMAIL PROTECTED] wrote:
I also haven't necessarily said what Ollie has proposed is a bad idea.
I have simply said the way he has come up with what he proposed is
not the way we should go about this. It may turn out he has come up
with exactly the representation we want (though I doubt this, for
various reasons).The specification given also doesn't even explain
where/how these operations can occur in GIMPLE, and what they do other
than a C++ something something.
Also given that someone already wrote a type-based devirtualizer that
worked fine, and i don't see how a points-to one is much work, I'd
like to see more justification for things like PTRMEM_PLUS_EXPR than
hey, the C++ FE generates this internally.
OK. It sounds like I need to go into a lot more detail. The new
nodes I've proposed aren't actually motivated by the C++ front end,
but rather by a consideration of the semantics dictated by the C++
standard. Naturally, this gives rise to some similarity, but for
instance, there is no PTRMEM_PLUS_EXPR in the C++ front end, and my
definition of PTRMEM_CST disagrees with the current node of the same
name.
Okay, so what exactly does all of the below complexity buy us over
lowering like Michael suggests, given that we can do devirtualization
(which seemed to be the motivating optimiation) without any of this?
We generally only add things to GIMPLE when there is a really
compelling reason. Other than it makes us not have to do
optimizations we are not going to stop doing anyway (IE addition of
constants like you give below).
Certainly, absolutely none of this helps type based devirtualization,
since it wouldn't care about any of the below except PTRMEM_REF.
As the points-to person, I can tell you none of this will give
points-to based devirtualization any benefit over completely lowering
it unless you were to implement flow-sensitive, context-sensitive
points-to (which is at least O(n^6) time, and currently, more than
that space wise).
We would see the lowered form as additions into a constant table, and
figure out the offset into that table, just as you are doing here.
To me, the only benefit is that you expose a higher level concept, but
i don't see any optimization potential except possible value numbering
of PTRMEM_CST nodes, which we get even on the lowered representation.
I'm really not trying to rain on your parade, I just don't see why
it's a win to do this. I'd be very convinced, however, if there was
something spectacular we could do that we can't do now. IE if there
are times we will never be able to recover the information, and it
enabled us to do something cool. I'd also be convinced if there were
tons of passes that could use this info to do something, and it was
non-trivial to reconstruct it (this is why i've always been in favor
of having a point in the compiler were array_ref was allowed on
pointers, or at least, we had the index info for indirect_ref's :P)
Right now, as Mark says, it seems the information is all still there,
even if it is a bit obfuscated, and I don't see why that many things
are going to care about digging it out.
I'd love to hear other opinions on the matter, of course :)
I
Let's walk through them:
PTRMEM_TYPE
Contains the types of the member (TREE_TYPE) and class
(TYPE_PTRMEM_BASETYPE) of this pointer to member. This is hopefully
self-explanatory. In the language of the C++ standard, it is the type
of a pointer to member of class TYPE_PTRMEM_BASETYPE of type
TREE_TYPE. This is the type of PTRMEM_CST's, PTRMEM_PLUS_EXPR's, and
various variable types (VAR_DECL, FIELD_DECL, PARM_DECL, etc.).
PTRMEM_CST
The C++ front end already has a PTRMEM_CST node. However, the
existing node only contains a class (PTRMEM_CST_CLASS) and member
(PTRMEM_CST_MEMBER), and is unable to represent an arbitrary pointer
to member value. This is especially evident when dealing with
multiple inheritance. Consider the following example:
struct B { int f (); };
struct L : B {};
struct R : B {};;
struct D : L, R {};
int (B::*pb)() = B::f;
int (L::*pl)() = pb;
int (R::*pr)() = pb;
int (D::*pd[2])() = { pl, pr };
In this case, pd[0] and pd[1] both have the same type and point to the
same member of the same class (B::f), but they point to different base
class instances of B. To represent this, we need an offset. Now, one
might argue that rather than a numeric offset, we should point to the
_DECL of the base class subobject, but that breaks down because the
following is also legal:
struct B {};
struct D : B { int f (); };
int (D::*pd)() = D::f;
int (B::*pb)() = static_castint (B::*)()(pd);
In this case, pb points to D::f in the derived class. Since there is
no subobject to point to, we see that a numeric offset representation
is required.
This leads to the definition of PTRMEM_CST which I have
Bootstrap failure on i386-pc-linux-gnu
My automated nightly build failed to bootstrap this evening on i386- pc-linux-gnu. This is for trunk rev. 127311, and the error is: /home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/ fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/ gfortran_nightbuild/irun-20070809/i386-pc-linux-gnu/bin/ -c -g - O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic- macros -Wno-overlength-strings -Werror- DHAVE_CONFIG_H -I. -I. -I/home/fx/gfortran_nightbuild/trunk/gcc -I/ home/fx/gfortran_nightbuild/trunk/gcc/. -I/home/fx/ gfortran_nightbuild/trunk/gcc/../include -I/home/fx/ gfortran_nightbuild/trunk/gcc/../libcpp/include -I/home/fx/ gfortran_nightbuild/software/include -I/home/fx/ gfortran_nightbuild/trunk/gcc/../libdecnumber -I/home/fx/ gfortran_nightbuild/trunk/gcc/../libdecnumber/bid -I../ libdecnumber/home/fx/gfortran_nightbuild/trunk/gcc/tree.c -o tree.o cc1: warnings being treated as errors /home/fx/gfortran_nightbuild/trunk/gcc/tree.c: In function 'initializer_zerop': /home/fx/gfortran_nightbuild/trunk/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type make[3]: *** [tree.o] Error 1 make[3]: Leaving directory `/home/fx/gfortran_nightbuild/ ibin-20070809/gcc' make[2]: *** [all-stage2-gcc] Error 2 I filed PR 33031 for this issue. Thanks, FX
can't bootstrap current trunk: internal compiler error: in simplify_subreg, at simplify-rtx.c:4679
Aurora SPARC Linux release 2.99 (Angel)/TI UltraSparc IIi (Sabre) sun4u: binutils-2.17.50.0.3-6.sparc.sparc bison-2.3-2.1.sparc dejagnu-1.4.4-5.1.noarch expect-5.43.0-5.1.sparc gcc-4.1.1-30.1.sparc glibc-2.5-3.1.sparcv9 glibc-2.5-3.1.sparc64 glibc-devel-2.5-3.1.sparc glibc-devel-2.5-3.1.sparc64 glibc-headers-2.5-3.1.sparc gmp-2.4.1 (local build from gcc's infrastructure) mpfr-2.2.1 (local build from gcc's infrastructure) kernel-2.6.21-1.3149.al3.12.sparc64 libgcc-4.1.1-30.1.sparc libgcc-4.1.1-30.1.sparc64 libstdc++-4.1.1-30.1.sparc libstdc++-4.1.1-30.1.sparc64 libstdc++-devel-4.1.1-30.1.sparc libstdc++-devel-4.1.1-30.1.sparc64 make-3.81-1.1.sparc tcl-8.4.13-3.al3.sparc LAST_UPDATED: Thu Aug 9 08:25:16 UTC 2007 (revision 127312) configure: --enable-__cxa_atexit --enable-shared --with-cpu=v7 --enable-languages=c,c++,fortran,java,objc,obj-c++,treelang --with-gmp=/usr/local/gmp-mpfr --with-mpfr=/usr/local/gmp-mpfr --with-long-double-128 /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../gcc/libgcc -I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc -I../../../gcc/libgcc/../include -DHAVE_CC_TLS -o _fixunssfdi.o -MT _fixunssfdi.o -MD -MP -MF _fixunssfdi.dep -DL_fixunssfdi -c ../../../gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../gcc/libgcc/../gcc/libgcc2.c: In function '__fixunssfdi': ../../../gcc/libgcc/../gcc/libgcc2.c:1348: internal compiler error: in simplify_subreg, at simplify-rtx.c:4679 Any ideas? Do you want me to post more info? -- Cheers, /ChJ
Fwd: Fixed function compilation order
Yesterday by mistake I started some private discussion with Daniel. I will forward his answer too. Begin forwarded message: From: Cupertino Miranda [EMAIL PROTECTED] Date: August 9, 2007 2:24:04 AM CEDT To: Daniel Berlin [EMAIL PROTECTED] Subject: Re: Fixed function compilation order On Aug 9, 2007, at 2:03 AM, Daniel Berlin wrote: On 8/8/07, Cupertino Miranda [EMAIL PROTECTED] wrote: Hello everyone, I am currently trying to enable GCC to perform compilation without having to respect any compilation order, i.e. execute some pass to any function at any time (it is not only pass reordering). As what I have seen from (trunk version of) GCC, it doesn't seem an easy task to be achieved and it might traduce in many complications later in development. In that sense I would like to have some opinions and suggestions from you all: For tree level optimization, this is really not difficult. For RTL, this is probably going to be really hard. - Imagining I am able to change the function context by updating cfun, etc. Will passes (all_passes) execute without missing/wrong data, i.e. is all shared data between passes accessed/ updated thought pointers such as cfun, etc. ? What do you mean missing/wrong data. Just as an example, imagine you just executed the pass for the creation of the CFG and after that, you decided to change context to another function to perform the same pass. Will I have to keep track of this CFG or it is also available and used (by other passes) through the high level structures pointed by cfun, etc. ? The CFG is just an example to possible very small detail data- structures that might exist in GCC and not such an obvious thing as a CFG. ;-) - What should I initialise/finalise to be able to perform the function context change ? See any IPA pass I would like to have your opinion and tips on how to approach it and which problems I might expect to have later. Thanks in advance, Cupertino Miranda
Fwd: Fixed function compilation order
Here is the answer. Begin forwarded message: From: Daniel Berlin [EMAIL PROTECTED] Date: August 9, 2007 2:31:08 AM CEDT To: Cupertino Miranda [EMAIL PROTECTED] Subject: Re: Fixed function compilation order On 8/8/07, Cupertino Miranda [EMAIL PROTECTED] wrote: On Aug 9, 2007, at 2:03 AM, Daniel Berlin wrote: On 8/8/07, Cupertino Miranda [EMAIL PROTECTED] wrote: Hello everyone, I am currently trying to enable GCC to perform compilation without having to respect any compilation order, i.e. execute some pass to any function at any time (it is not only pass reordering). As what I have seen from (trunk version of) GCC, it doesn't seem an easy task to be achieved and it might traduce in many complications later in development. In that sense I would like to have some opinions and suggestions from you all: For tree level optimization, this is really not difficult. For RTL, this is probably going to be really hard. - Imagining I am able to change the function context by updating cfun, etc. Will passes (all_passes) execute without missing/wrong data, i.e. is all shared data between passes accessed/ updated thought pointers such as cfun, etc. ? What do you mean missing/wrong data. Just as an example, imagine you just executed the pass for the creation of the CFG and after that, you decided to change context to another function to perform the same pass. Let me be clear. We create CFG/SSA for *all* functions at once right now, run a bunch of SSA passes, and then run a bunch of passes per-function. If you try to do something before this happens, yes, you will have issues. The simple answer is don't do that. :) So basically, you can throw your pass in the list of passes and expect changing functions to work like it does in an IPA pass. The one datastructure you cannot have stored on multiple functions at once right now are those related to tree level aliasing. We are fixing this, but it is not done yet.
Re: ICE on valid code, cse related
On Fri, Aug 03, 2007 at 03:49:32PM +0100, Dave Korn wrote: Yes, absolutely so, we already know that there are problems there. For references, see the threads Deep CSE bug![*] and Bogus REG_EQUIV note generation[**] (subject line was wrong, should have been REG_EQUAL all along) from June last year, where we got some way into analysing the problem. I /think/ that the presence of REG_RETVAL in this particular case is only tangential to the problem; from what I remember of the discussion, this is just about Gcc incorrectly handling reg notes when it decomposes multi-word-size-mode moves into individual word-sized moves. All examples so far have had CONST_DOUBLE in the REG_EQUAL note. Pranav, although there is indeed a bug in the mid-end here, from your point of view the simple and effective workaround should be to implement a movdi pattern (and movsf and movdf if you don't have them yet: it's an absolute requirement to implement movMM for any modes you expect your machine to handle) in the backend. If you look at the ia16 back end I posted, you'll notice that it only implements movXX for modes of 16 bits or less and AFAIK does not suffer from the CSE bug. -- Rask Ingemann Lambertsen
RE: ICE on valid code, cse related
On 09 August 2007 13:25, Rask Ingemann Lambertsen wrote: On Fri, Aug 03, 2007 at 03:49:32PM +0100, Dave Korn wrote: Yes, absolutely so, we already know that there are problems there. For references, see the threads Deep CSE bug![*] and Bogus REG_EQUIV note generation[**] (subject line was wrong, should have been REG_EQUAL all along) from June last year, where we got some way into analysing the problem. I /think/ that the presence of REG_RETVAL in this particular case is only tangential to the problem; from what I remember of the discussion, this is just about Gcc incorrectly handling reg notes when it decomposes multi-word-size-mode moves into individual word-sized moves. All examples so far have had CONST_DOUBLE in the REG_EQUAL note. Yes, and? I don't see what you're getting at here. Pranav, although there is indeed a bug in the mid-end here, from your point of view the simple and effective workaround should be to implement a movdi pattern (and movsf and movdf if you don't have them yet: it's an absolute requirement to implement movMM for any modes you expect your machine to handle) in the backend. If you look at the ia16 back end I posted, you'll notice that it only implements movXX for modes of 16 bits or less and AFAIK does not suffer from the CSE bug. It maybe latent for other reasons, or you may not have triggered it yet, but I wonder what kind of REG_EQUAL notes do you get when you start passing 32- (or even 64-) bit values around in 16-bit registers? cheers, DaveK -- Can't think of a witty .sigline today
Re: can't bootstrap current trunk: internal compiler error: in simplify_subreg,@simplify-rtx.c:4679
Hello,
the bootstrap failure you are seeing is caused by my decompose
multiword shift patch:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00419.html
It is the same failure as reported by Andreas Tobler:
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00533.html
I don't have access to a sparc machine. Could you please test the
following patch?
The patch at least seems to fix it on a cross gcc.
Bye,
-Andreas-
Index: gcc/lower-subreg.c
===
--- gcc/lower-subreg.c (revision 127312)
+++ gcc/lower-subreg.c (working copy)
@@ -1071,7 +1071,7 @@
GET_MODE (SET_DEST (set)),
offset2);
src_reg = simplify_gen_subreg_concatn (word_mode, op_operand,
- GET_MODE (op_operand),
+ GET_MODE (SET_DEST (set)),
src_offset);
if (GET_CODE (op) != ZERO_EXTEND)
{
can't bootstrap current trunk on cygwin: tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type
Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages: binutils 20060817-1 2.17.50 20060817 bison2.3-1 2.3 cygwin 1.5.24-2 (rev. 1.46 of newlib's stdio.h) dejagnu 20021217-2 1.4.2.x expect 20030128-1 5.26 gcc 3.4.4-3 gcc-ada 3.4.4-3 gcc-g++ 3.4.4-3 gmp 4.2.1-1 make 3.81-1 mpfr 2.2.1-1 tcltk20060202-1 8.4 w32api 3.10-1 LAST_UPDATED: Thu Aug 9 11:48:38 UTC 2007 (revision 127315) configure: --disable-nls --without-includ ed-gettext --enable-version-specific-runtime-libs --without-x --disable-libgcj --with-system-zlib --enable-threads=posix --enable-languages=c,c++,fortran,objc,obj-c++,treelang /usr/local/src/trunk/objdir/./prev-gcc/xgcc -B/usr/local/src/trunk/objdir/./prev-gcc/ -B/usr/local/i686-pc-cygwin/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc/gcc/tree.c -o tree.o cc1: warnings being treated as errors ../../gcc/gcc/tree.c: In function 'initializer_zerop': ../../gcc/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type make[3]: *** [tree.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [bootstrap] Error 2 Any ideas? -- Cheers, /ChJ
RE: can't bootstrap current trunk on cygwin: tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type
On 09 August 2007 14:39, Christian Joensson wrote: cc1: warnings being treated as errors ../../gcc/gcc/tree.c: In function 'initializer_zerop': ../../gcc/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type make[3]: *** [tree.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [bootstrap] Error 2 Any ideas? Yep, see the three other posts we've had about it so far this morning and maybe give the patch that was in the post just before yours a try cheers, DaveK -- Can't think of a witty .sigline today
mips gcc -O1: Address exception error on store doubleword
Hi,
I am seeing an address error exception caused by the gcc optimizer -O1.
I have narrowed it down to the following function:
static void varcopy(PVAR *pvar1, PVAR *pvar2) {
memcpy(pvar1,pvar2,sizeof(PVAR));
}
Being the sizeof(PVAR) 160 bytes.
The exception is caused on an sd instruction when the input is not
aligned on a doubleword boundary.
I was under the assumption that the compiler made sure that it doesn't
store a doubleword that is not aligned on a doubleword boundary. Is
this a bug in the optimizer?
I am using a gcc mips64 cross-compiler,
mips64-linux-gnu-gcc (GCC) 3.3-mips64linux-031001
Has anyone experienced this problem before?
Regards,
Alex
---
For reference,
The resulting code without optimizing is:
81024534 varcopy:
varcopy():
81024534:27bdffd0 addiusp,sp,-48
81024538:ffbf0020 sdra,32(sp)
8102453c:ffbe0018 sds8,24(sp)
81024540:ffbc0010 sdgp,16(sp)
81024544:03a0f02d moves8,sp
81024548:3c010009 luiat,0x9
8102454c:242108dc addiuat,at,2268
81024550:0039e02d daddugp,at,t9
81024554:afc4 swa0,0(s8)
81024558:afc50004 swa1,4(s8)
8102455c:8fc4 lwa0,0(s8)
81024560:8fc50004 lwa1,4(s8)
81024564:240600a0 lia2,160
81024568:8f99bd08 lwt9,-17144(gp)
8102456c:0320f809 jalrt9
81024570: nop
81024574:03c0e82d movesp,s8
81024578:dfbf0020 ldra,32(sp)
8102457c:dfbe0018 lds8,24(sp)
81024580:dfbc0010 ldgp,16(sp)
81024584:03e8 jrra
81024588:27bd0030 addiusp,sp,48
While the optimized code is:
8101b9d8 varcopy:
varcopy():
8101b9d8:24a200a0 addiuv0,a1,160
8101b9dc: nop
8101b9e0:dca3 ldv1,0(a1)
8101b9e4:dca60008 lda2,8(a1)
8101b9e8:dca70010 lda3,16(a1)
8101b9ec:dca80018 lda4,24(a1)
8101b9f0:fc83 sdv1,0(a0)
8101b9f4:fc860008 sda2,8(a0)
8101b9f8:fc870010 sda3,16(a0)
8101b9fc:fc880018 sda4,24(a0)
8101ba00:24a50020 addiua1,a1,32
8101ba04:14a2fff6 bnea1,v0,8101b9e0 varcopy+0x8
8101ba08:24840020 addiua0,a0,32
8101ba0c:03e8 jrra
8101ba10: nop
8101ba14: nop
Re: mips gcc -O1: Address exception error on store doubleword
Alex Gonzalez [EMAIL PROTECTED] writes: I was under the assumption that the compiler made sure that it doesn't store a doubleword that is not aligned on a doubleword boundary. Is this a bug in the optimizer? If the pointers are not correctly aligned for their target type then you are invoking undefined behaviour. If the aligment of PVAR is at least doubleword then the compiler may use doubleword accesses for copying. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: mips gcc -O1: Address exception error on store doubleword
Alex Gonzalez wrote:
Hi,
I am seeing an address error exception caused by the gcc optimizer -O1.
I have narrowed it down to the following function:
static void varcopy(PVAR *pvar1, PVAR *pvar2) {
memcpy(pvar1,pvar2,sizeof(PVAR));
}
Being the sizeof(PVAR) 160 bytes.
The exception is caused on an sd instruction when the input is not
aligned on a doubleword boundary.
I was under the assumption that the compiler made sure that it doesn't
store a doubleword that is not aligned on a doubleword boundary. Is
this a bug in the optimizer?
I am using a gcc mips64 cross-compiler,
mips64-linux-gnu-gcc (GCC) 3.3-mips64linux-031001
Has anyone experienced this problem before?
In order to investigate we would need a self contained test case (i.e.
the definition of PVAR must be included). Also it would be nice if you
could try it on a current version of GCC (4.2.1 perhaps).
David Daney
Re: mips gcc -O1: Address exception error on store doubleword
Hi,
I'll try to come up with a short test.
I have narrowed it a bit more. The PVAR structure contains a long long
variable ( with a sizeof 8 and an alignof 8 for my architecture). If I
take out the long long variable, the compiler uses sdl instructions
instead of sd and the exception doesn't happen.
Also, if I do
static void varcopy(void *pvar1, void *pvar2)
the compiler uses sdl and avoids the crash.
I am compiling for n32 ABI, so the register size is 64bits.
Any ideas?
On 8/9/07, David Daney [EMAIL PROTECTED] wrote:
Alex Gonzalez wrote:
Hi,
I am seeing an address error exception caused by the gcc optimizer -O1.
I have narrowed it down to the following function:
static void varcopy(PVAR *pvar1, PVAR *pvar2) {
memcpy(pvar1,pvar2,sizeof(PVAR));
}
Being the sizeof(PVAR) 160 bytes.
The exception is caused on an sd instruction when the input is not
aligned on a doubleword boundary.
I was under the assumption that the compiler made sure that it doesn't
store a doubleword that is not aligned on a doubleword boundary. Is
this a bug in the optimizer?
I am using a gcc mips64 cross-compiler,
mips64-linux-gnu-gcc (GCC) 3.3-mips64linux-031001
Has anyone experienced this problem before?
In order to investigate we would need a self contained test case (i.e.
the definition of PVAR must be included). Also it would be nice if you
could try it on a current version of GCC (4.2.1 perhaps).
David Daney
Re: mips gcc -O1: Address exception error on store doubleword
On Thursday 09 August 2007, Alex Gonzalez wrote: Hi, I'll try to come up with a short test. I have narrowed it a bit more. The PVAR structure contains a long long variable ( with a sizeof 8 and an alignof 8 for my architecture). If I take out the long long variable, the compiler uses sdl instructions instead of sd and the exception doesn't happen. Also, if I do static void varcopy(void *pvar1, void *pvar2) the compiler uses sdl and avoids the crash. I am compiling for n32 ABI, so the register size is 64bits. Any ideas? This is a bug in whatever calls varcopy. You told the complier that both were pointers to 8-byte aligned structures. If you lied, then the compiler is eintirely within its rights to generate code that explodes. You need to trace the values back to find out where the misalignment is coming from. Paul
RE: Bootstrap failure on i386-pc-linux-gnu
FX Coudert wrote: My automated nightly build failed to bootstrap this evening on i386- pc-linux-gnu. This is for trunk rev. 127311, and the error is: /home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/ fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/ gfortran_nightbuild/irun-20070809/i386-pc-linux-gnu/bin/ -c -g - O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic- macros -Wno-overlength-strings -Werror- DHAVE_CONFIG_H -I. -I. -I/home/fx/gfortran_nightbuild/trunk/gcc -I/ home/fx/gfortran_nightbuild/trunk/gcc/. -I/home/fx/ gfortran_nightbuild/trunk/gcc/../include -I/home/fx/ gfortran_nightbuild/trunk/gcc/../libcpp/include -I/home/fx/ gfortran_nightbuild/software/include -I/home/fx/ gfortran_nightbuild/trunk/gcc/../libdecnumber -I/home/fx/ gfortran_nightbuild/trunk/gcc/../libdecnumber/bid -I../ libdecnumber/home/fx/gfortran_nightbuild/trunk/gcc/tree.c -o tree.o cc1: warnings being treated as errors /home/fx/gfortran_nightbuild/trunk/gcc/tree.c: In function 'initializer_zerop': /home/fx/gfortran_nightbuild/trunk/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type make[3]: *** [tree.o] Error 1 make[3]: Leaving directory `/home/fx/gfortran_nightbuild/ ibin-20070809/gcc' make[2]: *** [all-stage2-gcc] Error 2 I filed PR 33031 for this issue. Thanks, FX Thanks a lot! I think this has been fixed by Michael Matz. 2007-08-09 Michael Matz [EMAIL PROTECTED] * tree.h (fixed_zerop): Declare as taking a const_tree. * tree.c (fixed_zerop): Take a const_tree. Regards, Chao-ying
Re: [RFC] Migrate pointers to members to the middle end
Ollie == Ollie Wild [EMAIL PROTECTED] writes: Ollie 1. Is pointer to member migration worthwhile? Can other languages Ollie besides C++ benefit from this? Not Java. You might ask Andrea about CLR though. Ollie 4. Is a migration of virtual functions and virtual function tables Ollie required? Are the various language implementations sufficiently Ollie similar to be handled by a common infrastructure? Java has 2 kinds of indirect function call (to be precise, this is the C++ ABI. The binary compatibility ABI is different -- but also isn't open to this kind of optimization). Virtual calls are implemented in a way that is compatible with C++. Interface calls are implemented in a different way. Tom
Re: [RFC] Migrate pointers to members to the middle end
Michael == Michael Matz [EMAIL PROTECTED] writes: Michael Yes, devirtualization. But I wonder if you really need class Michael hierarchies for this (actually I'm fairly sure you don't). I'm generally in favor of what you talked about in this note and others, and also Danny's overall approach of trying to design trees as a language-neutral IR. However, I'm not sure I agree with the above assertion. Specifically, for Java I think it is sometimes possible to strength reduce interface calls to virtual calls, but I don't see how this could be done without class hierarchy information. Also in Java it is possible to devirtualize calls in some situations where only a bound on the type is known. For instance at a call site we might know that all possible targets are derived from a class where the virtual method is final. I have no idea whether these cases matter, but they do exist. There are also type-related optimizations that can be done on Java that don't involve devirtualization. We have some code kicking around that does devirtualization and some other things for Java. We never put this in since it has a huge hack: the new passes aren't language-neutral and are added at runtime. Tom
Re: [RFC] Migrate pointers to members to the middle end
On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote: Also in Java it is possible to devirtualize calls in some situations where only a bound on the type is known. For instance at a call site we might know that all possible targets are derived from a class where the virtual method is final. Likewise in C++ we might know that a method is effectively final because no class overrides it.
Re: [RFC] Migrate pointers to members to the middle end
On Thu, Aug 09, 2007 at 02:11:34PM -0700, Joe Buck wrote: On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote: Also in Java it is possible to devirtualize calls in some situations where only a bound on the type is known. For instance at a call site we might know that all possible targets are derived from a class where the virtual method is final. I wrote: Likewise in C++ we might know that a method is effectively final because no class overrides it. Whoops, that didn't come out the way that I intended. I meant to say that we might know that a given method (member function) call is effectively final because no class that the pointer/reference can refer to overrides the call.
need help with builtin function prototypes
Could someone provide a hint for me? I'm trying to put in real prototypes for a builtin function where the arguments don't follow the default promotion rules. Specifically, one of the arguments is a reference type (like C++'s int). However, I'm bumping into two problems: 1. The compiler emits a compatibility warning: dj.c:4: warning: incompatible implicit declaration of built-in function 'mep_and' 2. The compiler seems to be using the implicit declaration instead of the builtin one, resulting in the builtin's arguments being incorrect, especially when optimizing: dj.c:4: error: non-lvalue passed to argument 1 of `mep_and' Is there a trick to this? I need this type of functionality because some builtins modify multiple values, so a simple return value is insufficient, plus this worked with older versions of gcc so our users are used to it syntax-wise. Parameters: reference_type 0xb7ee3680 type integer_type 0xb7e922d8 int public SI size integer_cst 0xb7e82228 constant invariant 32 unit size integer_cst 0xb7e82060 constant invariant 4 align 32 symtab 0 alias set -1 canonical type 0xb7e922d8 precision 32 min integer_cst 0xb7e821e0 -2147483648 max integer_cst 0xb7e821f8 2147483647 pointer_to_this pointer_type 0xb7e9b9c0 reference_to_this reference_type 0xb7ee3680 unsigned SI size integer_cst 0xb7e82228 32 unit size integer_cst 0xb7e82060 4 align 32 symtab 0 alias set -1 canonical type 0xb7ee3680 integer_type 0xb7e922d8 int public SI size integer_cst 0xb7e82228 type integer_type 0xb7e92068 bit_size_type constant invariant 32 unit size integer_cst 0xb7e82060 type integer_type 0xb7e92000 unsigned int constant invariant 4 align 32 symtab 0 alias set -1 canonical type 0xb7e922d8 precision 32 min integer_cst 0xb7e821e0 -2147483648 max integer_cst 0xb7e821f8 2147483647 pointer_to_this pointer_type 0xb7e9b9c0 Implicit function: function_type 0xb7eec618 type integer_type 0xb7ee02d8 int public SI size integer_cst 0xb7ed0228 constant invariant 32 unit size integer_cst 0xb7ed0060 constant invariant 4 align 32 symtab 0 alias set -1 canonical type 0xb7ee02d8 precision 32 min integer_cst 0xb7ed01e0 -2147483648 max integer_cst 0xb7ed01f8 2147483647 pointer_to_this pointer_type 0xb7ee99c0 reference_to_this reference_type 0xb7f31680 HI size integer_cst 0xb7ed0198 type integer_type 0xb7ee0068 bit_size_type constant invariant 16 unit size integer_cst 0xb7ed01b0 type integer_type 0xb7ee unsigned int constant invariant 2 align 16 symtab 0 alias set -1 structural equality Explicit function: function_type 0xb7f316e8 type void_type 0xb7ee95b0 void VOID align 8 symtab 0 alias set -1 canonical type 0xb7ee95b0 pointer_to_this pointer_type 0xb7ee9618 HI size integer_cst 0xb7ed0198 type integer_type 0xb7ee0068 bit_size_type constant invariant 16 unit size integer_cst 0xb7ed01b0 type integer_type 0xb7ee unsigned int constant invariant 2 align 16 symtab 0 alias set -1 structural equality arg-types tree_list 0xb7f34870 value reference_type 0xb7f31680 type integer_type 0xb7ee02d8 int unsigned SI size integer_cst 0xb7ed0228 constant invariant 32 unit size integer_cst 0xb7ed0060 constant invariant 4 align 32 symtab 0 alias set -1 canonical type 0xb7f31680 chain tree_list 0xb7f34858 value integer_type 0xb7ee02d8 int
cfg representation
Hi, I've been looking at the cfg that gcc dumps to a file. I'm noticing that the code is transformed in the cfg. Especially the short circuited expressions and the ternary operator for C/C++. Is there a particular algorithm gcc uses to transform the original AST into the modified version in the CFG? Does anyone know where the code is that does this transformation so I can look for myself? Thanks, Bob Rossi
Re: cfg representation
On 8/9/07 4:09 PM, Bob Rossi wrote: Does anyone know where the code is that does this transformation so I can look for myself? The conversion to GIMPLE does some of that, then the lowering into Low GIMPLE and the CFG cleanups do the rest. The files you want to look at are gimplify.c for all the conversion to GIMPLE, tree-cfg.c for the building of the CFG and omp-low.c for the conversion into Low GIMPLE. Documentation on the various parts of this process is a bit spotty, but you should find details on the various links in the Getting Started section of the GCC wiki (http://gcc.gnu.org/wiki/GettingStarted)
Re: [RFC] Migrate pointers to members to the middle end
Daniel Berlin wrote: This is the source of my current woes, as this may involve virtual function resolution, which can't be done with the information currently available to the middle end. Ollie, IIRC, you posted an example where, together with your front-end lowering patch (i.e., with the strategy that Daniel is advocating), we don't do some optimization that we could in theory do. Have you worked out why not? Perhaps that would shed some light on whether or not it's tractable to recover this information from our current IR. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.3.0 Status Report (2007-06-29)
Andreas Meier wrote: You have forgotten the regressions with target milestone 4.2.1 and without a target milestone. Thank you for pointing that out. The omission of 4.2.1 is definitely wrong, and I have fixed the front page with this patch. However, there should be no regressions without a target milestone, unless I've explicitly marked them that way, at some point. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving revision 1.626 diff -c -5 -p -r1.626 index.html *** index.html 21 Jul 2007 23:13:20 - 1.626 --- index.html 9 Aug 2007 22:52:08 - *** mission statement/a./p *** 127,140 /dtdd a href=http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html;2007-06-29/a (Stage 2). br / a ! href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.3amp;target_milestone=4.0.4amp;target_milestone=4.1.3amp;target_milestone=4.3.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;priority=P1amp;priority=P2amp;priority=P3amp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;cmdtype=doitamp;order=Reuse+same+sort+as+last+timeamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=;Serious regressions/a. a ! href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.3amp;target_milestone=4.0.4amp;target_milestone=4.1.3amp;target_milestone=4.3.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;cmdtype=doitamp;order=Reuse+same+sort+as+last+timeamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=;All regressions/a. /dd /dl --- 127,140 /dtdd a href=http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html;2007-06-29/a (Stage 2). br / a ! href=http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedamp;short_desc_type=allwordssubstramp;short_desc=4.3amp;target_milestone=4.0.4amp;target_milestone=4.1.3amp;target_milestone=4.2.2amp;target_milestone=4.3.0amp;known_to_fail_type=allwordssubstramp;known_to_work_type=allwordssubstramp;long_desc_type=allwordssubstramp;long_desc=amp;bug_file_loc_type=allwordssubstramp;bug_file_loc=amp;gcchost_type=allwordssubstramp;gcchost=amp;gcctarget_type=allwordssubstramp;gcctarget=amp;gccbuild_type=allwordssubstramp;gccbuild=amp;keywords_type=allwordsamp;keywords=amp;bug_status=UNCONFIRMEDamp;bug_status=NEWamp;bug_status=ASSIGNEDamp;bug_status=SUSPENDEDamp;bug_status=WAITINGamp;bug_status=REOPENEDamp;priority=P1amp;priority=P2amp;priority=P3amp;emailtype1=substringamp;email1=amp;emailtype2=substringamp;email2=amp;bugidtype=includeamp;bug_id=amp;votes=amp;chfieldfrom=amp;chfieldto=Nowamp;chfieldvalue=amp;cmdtype=doitamp;order=Reuse+same+sort+as+last+timeamp;field0-0-0=noopamp;type0-0-0=noopamp;value0-0-0=;Serious regressions/a. a !
Re: need help with builtin function prototypes
I'm hoping I can get it to do what I want, if only I can get the MI to treat the function definition given to it by the target as the one true definition, and not just some advisory one.
Re: [RFC] Migrate pointers to members to the middle end
On 8/9/07, Ollie Wild [EMAIL PROTECTED] wrote: On 8/9/07, Mark Mitchell [EMAIL PROTECTED] wrote: Daniel Berlin wrote: This is the source of my current woes, as this may involve virtual function resolution, which can't be done with the information currently available to the middle end. Ollie, IIRC, you posted an example where, together with your front-end lowering patch (i.e., with the strategy that Daniel is advocating), we don't do some optimization that we could in theory do. Have you worked out why not? Perhaps that would shed some light on whether or not it's tractable to recover this information from our current IR. The example I posted before indicated that the check to determine whether or not the member function is virtual wasn't optimized out. It didn't know that (fn_ptr 1) == 0. That should be easy to fix by incorporating pointer alignment requirements in fold_binary(). Offhand, I don't remember what happened with the various other cases, but my testing at the time wasn't particularly thorough. The feedback I've gotten so far seems overwhelmingly negative, so I think the next step is to revisit the lowering approach, exercise the hell out of it, and see what, if any, limitations pop up. Daniel mentioned something about a pre-existing type-based devirtualizer. I'd be interested to see how it works. From what I've been able to gleam from the GCC code, it seems that such an approach would need to hook back into the front end, which is a showstopper from an LTO perspective. It's entirely possible that I'm missing something, though. See http://gcc.gnu.org/ml/gcc-patches/2006-02/msg00744.html It only calls into the frontend to 1. Fold obj_type_ref_nodes (which would require *lowering* or defining the semantics of it, not raising) 2. Determine what is a ctor/dtor (something we do not expose to the middle-end) Ollie
Re: Your Gmail account, [EMAIL PROTECTED], has been created
Somebody signed up gcc@gcc.gnu.org to gmail. Bad sign.
Re: Your Gmail account, [EMAIL PROTECTED], has been created
- Original Message - From: Gmail Team [EMAIL PROTECTED] To: django porter gcc@gcc.gnu.org Sent: Thursday, August 09, 2007 6:21 PM Subject: Your Gmail account, [EMAIL PROTECTED], has been created Congratulations on creating your brand new Gmail account, [EMAIL PROTECTED] Please keep this email for your records, as it contains an important verification code that you may need should you ever encounter problems or forget your password. You can login to your account at http://mail.google.com/ Enjoy! The Gmail Team Verification code: f806a3e9-f1f6e619-bdc37c3949
Your Gmail account, [EMAIL PROTECTED], has been created
Congratulations on creating your brand new Gmail account, [EMAIL PROTECTED] Please keep this email for your records, as it contains an important verification code that you may need should you ever encounter problems or forget your password. You can login to your account at http://mail.google.com/ Enjoy! The Gmail Team Verification code: f806a3e9-f1f6e619-bdc37c3949
Re: need help with builtin function prototypes
DJ Delorie [EMAIL PROTECTED] writes: Is there a trick to this? I need this type of functionality because some builtins modify multiple values, so a simple return value is insufficient, plus this worked with older versions of gcc so our users are used to it syntax-wise. I've never found a good solution for builtins which return multiple values. The best approximation I found was to return a magic structure, and to provide other builtin functions to get the values from the structure (defining the structure in the backend was problematic when using C++). It doesn't sound like that will help you, though, if you are stuck with the existing syntax. Ian
Re: [RFC] Migrate pointers to members to the middle end
On 8/9/07, Mark Mitchell [EMAIL PROTECTED] wrote: Daniel Berlin wrote: This is the source of my current woes, as this may involve virtual function resolution, which can't be done with the information currently available to the middle end. Ollie, IIRC, you posted an example where, together with your front-end lowering patch (i.e., with the strategy that Daniel is advocating), we don't do some optimization that we could in theory do. Have you worked out why not? Perhaps that would shed some light on whether or not it's tractable to recover this information from our current IR. The example I posted before indicated that the check to determine whether or not the member function is virtual wasn't optimized out. It didn't know that (fn_ptr 1) == 0. That should be easy to fix by incorporating pointer alignment requirements in fold_binary(). Offhand, I don't remember what happened with the various other cases, but my testing at the time wasn't particularly thorough. The feedback I've gotten so far seems overwhelmingly negative, so I think the next step is to revisit the lowering approach, exercise the hell out of it, and see what, if any, limitations pop up. Daniel mentioned something about a pre-existing type-based devirtualizer. I'd be interested to see how it works. From what I've been able to gleam from the GCC code, it seems that such an approach would need to hook back into the front end, which is a showstopper from an LTO perspective. It's entirely possible that I'm missing something, though. Ollie
Re: [RFC] Migrate pointers to members to the middle end
On 8/9/07, Joe Buck [EMAIL PROTECTED] wrote: On Thu, Aug 09, 2007 at 02:29:28PM -0600, Tom Tromey wrote: Also in Java it is possible to devirtualize calls in some situations where only a bound on the type is known. For instance at a call site we might know that all possible targets are derived from a class where the virtual method is final. Likewise in C++ we might know that a method is effectively final because no class overrides it. Just to be clear, we *already* have the class hierarchies in the middle end. They have been there for a few years now :)
GCC 4.3.0 Status Report (2007-08-09)
Summary --- We entered Stage 2 on July 6th. I plan to put us into Stage 3 on September 10th. At that point, we will accept only bug-fixes -- no more new features until Stage 1 for GCC 4.4. Are there any folks out there who have projects for Stage 1 or Stage 2 that they are having trouble getting reviewed? Any comments re. timing for Stage 3? Quality --- At this point, we have 194 P3-or-higher regressions open against 4.3.0: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advancedshort_desc_type=allwordssubstrshort_desc=4.3target_milestone=4.0.4target_milestone=4.1.3target_milestone=4.2.2target_milestone=4.3.0known_to_fail_type=allwordssubstrknown_to_work_type=allwordssubstrlong_desc_type=allwordssubstrlong_desc=bug_file_loc_type=allwordssubstrbug_file_loc=gcchost_type=allwordssubstrgcchost=gcctarget_type=allwordssubstrgcctarget=gccbuild_type=allwordssubstrgccbuild=keywords_type=allwordskeywords=bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=SUSPENDEDbug_status=WAITINGbug_status=REOPENEDpriority=P1priority=P2priority=P3emailtype1=substringemail1=emailtype2=substringemail2=bugidtype=includebug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=doitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0-0=noopvalue0-0-0= I have not yet triaged the many P3 bugs, so I expect that some of these will be downgraded. An interesting fact is that now about half of the 34 P1s re 4.3-only regressions. So, we have been introducing some new and exciting bugs, and we need to fix those. Do we need another 1-week stabilization period? Previous Report --- http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: need help with builtin function prototypes
On Thu, 9 Aug 2007, DJ Delorie wrote: Could someone provide a hint for me? I'm trying to put in real prototypes for a builtin function where the arguments don't follow the default promotion rules. Specifically, one of the arguments is a reference type (like C++'s int). However, I'm bumping into two problems: 1. The compiler emits a compatibility warning: dj.c:4: warning: incompatible implicit declaration of built-in function 'mep_and' 2. The compiler seems to be using the implicit declaration instead of the builtin one, resulting in the builtin's arguments being incorrect, especially when optimizing: dj.c:4: error: non-lvalue passed to argument 1 of `mep_and' Is there a trick to this? I need this type of functionality because some builtins modify multiple values, so a simple return value is insufficient, plus this worked with older versions of gcc so our users are used to it syntax-wise. I don't know about using reference types, but there are several math builtins that return multiple values, the extra ones via pointer arguments. E.g. see frexp, lgamma_r, modf, remquo and/or sincos. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: need help with builtin function prototypes
I don't know about using reference types, but there are several math builtins that return multiple values, the extra ones via pointer arguments. E.g. see frexp, lgamma_r, modf, remquo and/or sincos. Like I said, I'm kinda locked into the syntax. People have been using these builtins for many years now. Everything was fine when we expanded the builtins to insns before optimization, and we could block optimizations using RTL, but we don't have that option with tree optimizations.
Re: can't bootstrap current trunk: internal compiler error: in simplify_subreg,@simplify-rtx.c:4679
On Thu, 9 Aug 2007, Andreas Krebbel wrote: Hello, the bootstrap failure you are seeing is caused by my decompose multiword shift patch: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00419.html It is the same failure as reported by Andreas Tobler: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00533.html I don't have access to a sparc machine. Could you please test the following patch? The patch at least seems to fix it on a cross gcc. Bye, -Andreas- I have the same bootstrap error on sparc-sun-solaris2.10. Your patch does not fix it for me. It moves the error to another line: .../libgcc/../gcc/libgcc2.c: In function '__fixunssfdi': .../libgcc/../gcc/libgcc2.c:1348: internal compiler error: in simplify_subreg, at simplify-rtx.c:4674 Try: cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mcpu=v9 -auxbase-strip _fixunssfdi.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fkeep-inline-functions -fPIC -o libgcc2.s Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED] libgcc2.i.gz Description: libgcc2.i.gz
free touble
hi, all
i want to ask, why free function did not do properly as it expected
(happened in test_malloc.c), the usage memory (using malloc) still exist
please help me, i have another program it, doing malloc continously, and
free it when not needed, this happened several times,
after some looping, my memory become 0 free, and it got hang.i did some
investigation, and found there is something strange in free.
anyone got idea what happen and give me a solution?
thanks in advance
Johny Jugianto
using gcc:
$ gcc --version
gcc (GCC) 4.2.0
here is my machine info
$ uname -a
Linux localhost.svr 2.6.9-55.ELsmp #1 SMP Wed May 2 14:28:44 EDT 2007 i686
athlon i386 GNU/Linux
-RESULT: pmap for test_malloc.c after ready to insert-
[EMAIL PROTECTED] ~]$ pmap 5836
5836: ./test_malloc
007ad000 88K r-x-- /lib/ld-2.3.4.so
007c3000 4K r /lib/ld-2.3.4.so
007c4000 4K rw--- /lib/ld-2.3.4.so
007c7000 1176K r-x-- /lib/tls/libc-2.3.4.so
008ed000 8K r /lib/tls/libc-2.3.4.so
008ef000 8K rw--- /lib/tls/libc-2.3.4.so
008f1000 8K rw---[ anon ]
08048000 4K r-x-- /home/nyto/test_malloc
08049000 4K rw--- /home/nyto/test_malloc
08dcb000132K rw---[ anon ]
b7ba2000 3920K rw---[ anon ]
bfff 64K rw---[ stack ]
e000 4K -[ anon ]
total 5424K
-RESULT: pmap for test_malloc.c after done free---
[EMAIL PROTECTED] ~]$ pmap 5836
5836: ./test_malloc
007ad000 88K r-x-- /lib/ld-2.3.4.so
007c3000 4K r /lib/ld-2.3.4.so
007c4000 4K rw--- /lib/ld-2.3.4.so
007c7000 1176K r-x-- /lib/tls/libc-2.3.4.so
008ed000 8K r /lib/tls/libc-2.3.4.so
008ef000 8K rw--- /lib/tls/libc-2.3.4.so
008f1000 8K rw---[ anon ]
08048000 4K r-x-- /home/nyto/test_malloc
08049000 4K rw--- /home/nyto/test_malloc
08dcb000 15708K rw---[ anon ]
b7ba2000 3920K rw---[ anon ]
bfff 64K rw---[ stack ]
e000 4K -[ anon ]
total21000K
-RESULT: pmap for test_malloc2.c after ready to insert
[EMAIL PROTECTED] ~]$ pmap 5841
5841: ./test_malloc2
007ad000 88K r-x-- /lib/ld-2.3.4.so
007c3000 4K r /lib/ld-2.3.4.so
007c4000 4K rw--- /lib/ld-2.3.4.so
007c7000 1176K r-x-- /lib/tls/libc-2.3.4.so
008ed000 8K r /lib/tls/libc-2.3.4.so
008ef000 8K rw--- /lib/tls/libc-2.3.4.so
008f1000 8K rw---[ anon ]
08048000 4K r-x-- /home/nyto/test_malloc2
08049000 4K rw--- /home/nyto/test_malloc2
087c3000132K rw---[ anon ]
b7baa000 3920K rw---[ anon ]
bfee6000 1128K rw---[ stack ]
e000 4K -[ anon ]
total 6488K
-RESULT: pmap for test_malloc2.c after done free--
[EMAIL PROTECTED] ~]$ pmap 5841
5841: ./test_malloc2
007ad000 88K r-x-- /lib/ld-2.3.4.so
007c3000 4K r /lib/ld-2.3.4.so
007c4000 4K rw--- /lib/ld-2.3.4.so
007c7000 1176K r-x-- /lib/tls/libc-2.3.4.so
008ed000 8K r /lib/tls/libc-2.3.4.so
008ef000 8K rw--- /lib/tls/libc-2.3.4.so
008f1000 8K rw---[ anon ]
08048000 4K r-x-- /home/nyto/test_malloc2
08049000 4K rw--- /home/nyto/test_malloc2
087c3000132K rw---[ anon ]
b7baa000 3920K rw---[ anon ]
bfee6000 1128K rw---[ stack ]
e000 4K -[ anon ]
total 6488K
-FILE: test_malloc.c--
#includestdio.h
#includestdlib.h
#includestring.h
#define JUMLAH 100
#define ISI 100
typedef struct _dodol
{
char *abc;
} dodol;
int main()
{
dodol **abc = (dodol**)calloc( JUMLAH, sizeof(dodol*) );
char *lala = (char*)malloc(sizeof(char)*ISI +1);
int i;
char a[10];
for(i=0; iISI; i++)
lala[i] = 'a';
lala[i]=0;
printf(ready to insert\n);
scanf(%s,a);
for(i=0; iJUMLAH; i++) {
abc[i] = (dodol *)malloc(sizeof(dodol));
//free( abc[i] );
}
//printf(ready to free\n);
//scanf(%s,a);
for(i=0; iJUMLAH; i++) {
free( abc[i] );
}
//free(abc);
printf(done free\n);
scanf(%s,a);
return 0;
}
-FILE: test_malloc2.c-
#includestdio.h
#includestdlib.h
#includestring.h
#define JUMLAH 100
#define ISI 100
typedef struct _dodol
{
char *abc;
} dodol;
int main()
{
dodol **abc = (dodol**)calloc( JUMLAH, sizeof(dodol*) );
char *lala = (char*)malloc(sizeof(char)*ISI +1);
int i;
char a[10];
for(i=0; iISI; i++)
lala[i] = 'a';
lala[i]=0;
printf(ready to insert\n);
scanf(%s,a);
for(i=0; iJUMLAH; i++) {
abc[i] = (dodol *)malloc(sizeof(dodol));
free( abc[i] );
}
//printf(ready to free\n);
//scanf(%s,a);
[Bug bootstrap/33031] New: Bootstrap fails on gcc/tree.c
My automated nightly build failed to bootstrap this evening on i386-pc-linux-gnu. This is for trunk rev. 127311, and the error is: /home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/gfortran_nightbuild/irun-20070809/i386-pc-linux-gnu/bin/ -c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror-DHAVE_CONFIG_H -I. -I. -I/home/fx/gfortran_nightbuild/trunk/gcc -I/home/fx/gfortran_nightbuild/trunk/gcc/. -I/home/fx/gfortran_nightbuild/trunk/gcc/../include -I/home/fx/gfortran_nightbuild/trunk/gcc/../libcpp/include -I/home/fx/gfortran_nightbuild/software/include -I/home/fx/gfortran_nightbuild/trunk/gcc/../libdecnumber -I/home/fx/gfortran_nightbuild/trunk/gcc/../libdecnumber/bid -I../libdecnumber /home/fx/gfortran_nightbuild/trunk/gcc/tree.c -o tree.o cc1: warnings being treated as errors /home/fx/gfortran_nightbuild/trunk/gcc/tree.c: In function 'initializer_zerop': /home/fx/gfortran_nightbuild/trunk/gcc/tree.c:7694: error: passing argument 1 of 'fixed_zerop' discards qualifiers from pointer target type make[3]: *** [tree.o] Error 1 make[3]: Leaving directory `/home/fx/gfortran_nightbuild/ibin-20070809/gcc' make[2]: *** [all-stage2-gcc] Error 2 -- Summary: Bootstrap fails on gcc/tree.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org GCC build triplet: i386-pc-linux-gnu GCC host triplet: i386-pc-linux-gnu GCC target triplet: i386-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33031
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #4 from andreasmeier80 at gmx dot de 2007-08-09 08:43 --- It worked well with r126900, but did not with r126976 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug bootstrap/33031] Bootstrap fails on gcc/tree.c
--- Comment #1 from irar at il dot ibm dot com 2007-08-09 08:44 --- I got this too on x86_64-linux. I guess the guilty patch is r127306 | chaoyingfu | 2007-08-09 01:29:12 +0300 (Thu, 09 Aug 2007) | 213 lines since it added the function fixed_zerop: * tree.c ... (fixed_zerop): New function. Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33031
[Bug c/33033] New: FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2'
Aurora SPARC Linux release 2.99 (Angel)/TI UltraSparc IIi (Sabre) sun4u: binutils-2.17.50.0.3-6.sparc.sparc bison-2.3-2.1.sparc dejagnu-1.4.4-5.1.noarch expect-5.43.0-5.1.sparc gcc-4.1.1-30.1.sparc glibc-2.5-3.1.sparcv9 glibc-2.5-3.1.sparc64 glibc-devel-2.5-3.1.sparc glibc-devel-2.5-3.1.sparc64 glibc-headers-2.5-3.1.sparc gmp-2.4.1 (local build from gcc's infrastructure) mpfr-2.2.1 (local build from gcc's infrastructure) kernel-2.6.21-1.3149.al3.12.sparc64 libgcc-4.1.1-30.1.sparc libgcc-4.1.1-30.1.sparc64 libstdc++-4.1.1-30.1.sparc libstdc++-4.1.1-30.1.sparc64 libstdc++-devel-4.1.1-30.1.sparc libstdc++-devel-4.1.1-30.1.sparc64 make-3.81-1.1.sparc tcl-8.4.13-3.al3.sparc LAST_UPDATED: Mon Aug 6 09:19:03 UTC 2007 (revision 127237) test results posted at http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00248.html In the gcc testsuite, (--with-cpu=v7) I get this failure: PASS: gcc.dg/20061026.c (test for excess errors) Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ /usr/local/src/branch/gcc/gcc/testsuite/gcc.dg/20061124-1.c-ansi -pedantic-errors -fno-show-column -lm -o ./20061124-1.exe(timeout = 1200) /tmp/cc0xZZ4Z.o: In function `main': 20061124-1.c:(.text+0x14): undefined reference to `__sync_add_and_fetch_2' collect2: ld returned 1 exit status compiler exited with status 1 output is: /tmp/cc0xZZ4Z.o: In function `main': 20061124-1.c:(.text+0x14): undefined reference to `__sync_add_and_fetch_2' collect2: ld returned 1 exit status FAIL: gcc.dg/20061124-1.c (test for excess errors) Excess errors: 20061124-1.c:(.text+0x14): undefined reference to `__sync_add_and_fetch_2' WARNING: gcc.dg/20061124-1.c compilation failed to produce executable -- Summary: FAIL: gcc.dg/20061124-1.c: undefined reference to `__sync_add_and_fetch_2' Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot joensson at gmail dot com GCC build triplet: sparc64-unknown-linu-gnu GCC host triplet: sparc64-unknown-linu-gnu GCC target triplet: sparc64-unknown-linu-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33033
[Bug c/33034] New: FAIL: gcc.c-torture/unsorted/DFcmp.c SFset.c: internal compiler error: in extract_insn, at recog.c:2077
Aurora SPARC Linux release 2.99 (Angel)/TI UltraSparc IIi (Sabre) sun4u: binutils-2.17.50.0.3-6.sparc.sparc bison-2.3-2.1.sparc dejagnu-1.4.4-5.1.noarch expect-5.43.0-5.1.sparc gcc-4.1.1-30.1.sparc glibc-2.5-3.1.sparcv9 glibc-2.5-3.1.sparc64 glibc-devel-2.5-3.1.sparc glibc-devel-2.5-3.1.sparc64 glibc-headers-2.5-3.1.sparc gmp-2.4.1 (local build from gcc's infrastructure) mpfr-2.2.1 (local build from gcc's infrastructure) kernel-2.6.21-1.3149.al3.12.sparc64 libgcc-4.1.1-30.1.sparc libgcc-4.1.1-30.1.sparc64 libstdc++-4.1.1-30.1.sparc libstdc++-4.1.1-30.1.sparc64 libstdc++-devel-4.1.1-30.1.sparc libstdc++-devel-4.1.1-30.1.sparc64 make-3.81-1.1.sparc tcl-8.4.13-3.al3.sparc LAST_UPDATED: Mon Aug 6 09:19:03 UTC 2007 (revision 127237) test results posted at http://gcc.gnu.org/ml/gcc-testresults/2007-08/msg00248.html In the gcc testsuite, (--with-cpu=v7, but also -m64), I get these failures: Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ -w -O1 -fno-show-column -c -m64 -o /usr/local/src/branch/objdir/gcc/testsuite/gcc/DFcmp.o /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c (timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 37 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [0 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 37 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [0 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.c-torture/unsorted/DFcmp.c, -O1 (internal compiler error) Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ -w -O2 -fno-show-column -c -m64 -o /usr/local/src/branch/objdir/gcc/testsuite/gcc/DFcmp.o /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c (timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 39 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [8 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. compiler exited with status 1 output is: /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 39 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [8 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.c-torture/unsorted/DFcmp.c, -O2 (internal compiler error) Executing on host: /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ -w -O3 -fomit-frame-pointer -fno-show-column -c -m64 -o /usr/local/src/branch/objdir/gcc/testsuite/gcc/DFcmp.o /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c (timeout = 1200) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c: In function 'reg0limm1': /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: error: unrecognizable insn: (insn 39 14 15 2 (set (reg:DI 42 %f10) (mem/u/c/i:DI (symbol_ref/u:DI (*.LLC1) [flags 0x2]) [8 S8 A64])) -1 (nil) (nil)) /usr/local/src/branch/gcc/gcc/testsuite/gcc.c-torture/unsorted/DFcmp.c:39: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See
[Bug middle-end/33030] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-09 09:08 --- *** This bug has been marked as a duplicate of 33029 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Summary|libgcc2.c:1890: internal|libgcc2.c:1890: internal |compiler error: in local_cpr|compiler error: in |op_pass, at gcse.c:3236 |local_cprop_pass, at ||gcse.c:3236 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33030
[Bug middle-end/33029] libgcc2.c:1890: internal compiler error: in local_cpr op_pass, at gcse.c:3236
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-08-09 09:08 --- *** Bug 33030 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
[Bug middle-end/33029] [4.3 Regression] libgcc2.c:1890: internal compiler error: in local_cprop_pass, at gcse.c:3236
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||build, ice-on-valid-code Summary|libgcc2.c:1890: internal|[4.3 Regression] |compiler error: in local_cpr|libgcc2.c:1890: internal |op_pass, at gcse.c:3236 |compiler error: in ||local_cprop_pass, at ||gcse.c:3236 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33029
[Bug c++/33025] [4.3 Regression] Wrong calling of placement new with conditionals
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-09 09:18 --- Because placement new is required to reproduce this bug and the front-end is where the broken code happens already, then the patch to fix PR 29286 is the cause. The problem is in build_new_1 where we create a temp variable to hold the placement variable is initialized with the value of the placement new which is wrong as we don't get that initialization inside the conditional. You can most likely reduce this testcase further using printf instead of cout and saying if you call operator() too many times to abort. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ian at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Last reconfirmed|-00-00 00:00:00 |2007-08-09 09:18:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33025
[Bug fortran/31629] option to make module entities PRIVATE by default
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-09 09:35
---
What about the following:
Index: gfortran.h
===
--- gfortran.h (revision 127224)
+++ gfortran.h (working copy)
@@ -1865,6 +1865,7 @@ typedef struct
int flag_d_lines;
int flag_openmp;
int flag_sign_zero;
+ int flag_module_private;
int fpe;
Index: lang.opt
===
--- lang.opt(revision 127224)
+++ lang.opt(working copy)
@@ -212,6 +212,10 @@ fmax-stack-var-size=
Fortran RejectNegative Joined UInteger
-fmax-stack-var-size=n Size in bytes of the largest array that will be
put on the stack
+fmodule-private
+Fortran
+Set default accessibility of module entities to PRIVATE.
+
fopenmp
Fortran
Enable OpenMP
Index: module.c
===
--- module.c(revision 127224)
+++ module.c(working copy)
@@ -3714,7 +3714,10 @@ gfc_check_access (gfc_access specific_ac
if (specific_access == ACCESS_PRIVATE)
return FALSE;
- return default_access != ACCESS_PRIVATE;
+ if (gfc_option.flag_module_private)
+return default_access == ACCESS_PUBLIC;
+ else
+return default_access != ACCESS_PRIVATE;
}
Index: options.c
===
--- options.c (revision 127224)
+++ options.c (working copy)
@@ -93,6 +93,7 @@ gfc_init_options (unsigned int argc ATTR
gfc_option.flag_preprocessed = 0;
gfc_option.flag_automatic = 1;
gfc_option.flag_backslash = 1;
+ gfc_option.flag_module_private = 0;
gfc_option.flag_backtrace = 0;
gfc_option.flag_allow_leading_underscore = 0;
gfc_option.flag_dump_core = 0;
@@ -575,6 +576,10 @@ gfc_handle_option (size_t scode, const c
gfc_option.flag_max_stack_var_size = value;
break;
+case OPT_fmodule_private:
+ gfc_option.flag_module_private = value;
+ break;
+
case OPT_frange_check:
gfc_option.flag_range_check = value;
break;
Index: invoke.texi
===
--- invoke.texi (revision 127228)
+++ invoke.texi (working copy)
@@ -121,7 +121,7 @@ by type. Explanations are in the follow
[EMAIL PROTECTED] -ffixed-line-length-none @gol
[EMAIL PROTECTED] -ffree-line-length-none @gol
-fdefault-double-8 -fdefault-integer-8 -fdefault-real-8 @gol
--fcray-pointer -fopenmp -frange-check -fno-backslash }
+-fcray-pointer -fopenmp -frange-check -fno-backslash -fmodule-private}
@item Error and Warning Options
@xref{Error and Warning Options,,Options to request or suppress errors
@@ -238,6 +238,14 @@ Allow @samp{$} as a valid character in a
Change the interpretation of backslashes in string literals from
``C-style'' escape characters to a single backslash character.
[EMAIL PROTECTED] -fmodule-private
[EMAIL PROTECTED] @code{fmodule-private}
[EMAIL PROTECTED] module entities
[EMAIL PROTECTED] private
+Set the default accessibility of module entities to @code{PRIVATE}.
+Use-associated entities will not be accessible unless they are explicitly
+declared as @code{PUBLIC}.
+
@item [EMAIL PROTECTED]
@opindex @[EMAIL PROTECTED]
@cindex file format, fixed
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug middle-end/32820] optimizer malfunction when mixed with asm statements
--- Comment #4 from jbuehler at spirentcom dot com 2007-08-09 11:38 --- Created an attachment (id=14045) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14045action=view) gcc 4.0.4 global register variable optimizer patch The attached patch fixes the optimizer bug for gcc 4.0.4 and allows GHC 6.6.1 to be compiled with optimization turned on. The problem is that lifetime analysis is marking global registers as REG_UNUSED and then the combiner pass is eliminating them. The fix is to not mark global registers as unused. The fix is based on a review of the flow.c code for gcc 4.2.0. Code was added to flow.c somewhere after 4.0.4 to handle stack registers and no mark them as REG_UNUSED. This patch merely mimics stack register handling in flow.c for global registers. I am not a gcc expert and make no claims for the correctness of this patch -- it does fix my ghc compile though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32820
[Bug c++/33035] New: ICE on local class destructor. Regression?
gcc-4.3-20070727 fails with ICE on code:
---
templateclass A
struct a {
templateclass B
struct b {
templateclass C
void f()
{
struct g
{
~g() {}//--here
};
}
};
};
---
Compiler output is:
---
G++ -v -save-temps gcc-err.cpp
Using built-in specs.
Target: i686-pc-mingw32
Configured with: ../gcc-4.3-20070727/configure --disable-bootstrap
--enable-languages=c,c++ --with-gcc --with-gnu-ld --with-gnu-as --with-dwarf2
--without-stabs --disable-sjlj-exceptions --prefix=/mingw
--libexecdir=/mingw/lib --disable-werror --enable-threads --disable-nls
--disable-win32-registry --disable-shared --disable-libssp
--disable-libstdcxx-debug --disable-concept-checks
Thread model: win32
gcc version 4.3.0 20070727 (experimental)
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/cc1plus.exe -E -quiet -v -iprefix
d:\tools\gcc\bin\../lib/gcc/i686-pc-mingw32/4.3.0/ gcc-err.cpp -mtune=generic
-fpch-preprocess -o gcc-err.ii
#include ... search starts here:
#include ... search starts here:
d:\TOOLS\GCC/include
d:\TOOLS\GCC/local/include
d:\TOOLS\GCC/win32api/include
d:/prj/libs/include
d:/prj/libs/boost
d:\tools\gcc\bin\../lib/gcc/i686-pc-mingw32/4.3.0/include
d:\tools\gcc\bin\../lib/gcc/i686-pc-mingw32/4.3.0/include-fixed
d:/TOOLS/GCC/include/c++/4.3.0
d:/TOOLS/GCC/include/c++/4.3.0/i686-pc-mingw32
d:/TOOLS/GCC/include/c++/4.3.0/backward
d:/TOOLS/GCC/include
d:/TOOLS/GCC/include
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/include
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/include-fixed
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/include-fixed
d:/TOOLS/GCC/include
End of search list.
d:/TOOLS/GCC/lib/gcc/i686-pc-mingw32/4.3.0/cc1plus.exe -fpreprocessed
gcc-err.ii -quiet -dumpbase gcc-err.cpp -mtune=generic -auxbase gcc-err
-version -o gcc-err.s
GNU C++ version 4.3.0 20070727 (experimental) (i686-pc-mingw32)
compiled by GNU C version 4.2.0, GMP version 4.2.1, MPFR version 2.2.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b6f7d618f50d2b0792a732058b53d781
gcc-err.cpp: In member function 'void aA::bB::f()':
gcc-err.cpp:10: internal compiler error: tree check: expected class 'type',
have 'declaration' (function_decl) in push_template_decl_real, at cp/pt.c:3917
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
---
3.4.2, 4.1.1 and 4.2.0 compile it well.
--
Summary: ICE on local class destructor. Regression?
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vasili dot burdo at gmail dot com
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33035
[Bug c++/33025] [4.3 Regression] Wrong calling of placement new with conditionals
--- Comment #4 from theodore dot papadopoulo at sophia dot inria dot fr 2007-08-09 12:02 --- Created an attachment (id=14046) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14046action=view) A new more minimal test case The same program was still working with gcc version 4.3.0 20070608 (experimental). This reduces slightly the bug introduction window even though it looks that Andrew already spotted the exact patch that introduced the bug (By the way thank's a lot!!). grenade- /usr/local/gcc-4.3/bin/g++ Bug.C grenade- /usr/local/gcc-4.3/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /user/papadop/laptop/home/src/Cvs/Refs/gcc/gcc-svn-ref/trunk/configure --prefix=/usr/local/gcc-4.3/ --enable-languages=c,c++,fortran --enable-__cxa_atexit Thread model: posix gcc version 4.3.0 20070703 (experimental) grenade- ./a.out Abort grenade- g++ Bug.C grenade- g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) grenade- ./a.out grenade- /usr/local/gcc-4.3.old/bin/g++ Bug.C grenade- /usr/local/gcc-4.3.old/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /user/papadop/laptop/home/src/Cvs/Refs/gcc/gcc-svn-ref/trunk/configure --prefix=/usr/local/gcc-4.3/ --enable-languages=c,c++,fortran --enable-__cxa_atexit Thread model: posix gcc version 4.3.0 20070608 (experimental) grenade- ./a.out -- theodore dot papadopoulo at sophia dot inria dot fr changed: What|Removed |Added Attachment #14043|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33025
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #5 from andreasmeier80 at gmx dot de 2007-08-09 12:52 --- It worked well with r126941, but did not with r126959 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug target/33036] New: LINUX_DYNAMIC_LINKER undefined in gcc-4.2.1/gcc/config/arm/linux-elf.h
Hello! The undefined variable LINUX_DYNAMIC_LINKER, included in the Variable LINK_SPEC in the file gcc-4.2.1/gcc/config/arm/linux-elf.h lines 56-68 causes an error during compilation of gcc-4.2.1/gcc/gcc.c at line 740. The error was: path/gcc-4.2.1/gcc/gcc.c:740: error: expected , or ; before LINUX_DYNAMIC_LINKER Defining this variable fixed the compilation problem. I assume, a reasonable value would be e.g. #define GLIBC_DYNAMIC_LINKER /lib/ld-linux.so.2 #define LINUX_DYNAMIC_LINKER GLIBC_DYNAMIC_LINKER and will solve this problem at once. I looked up, how this variable was defined in other architecture header files e.g. at gcc-4.2.1/gcc/config/alpha/linux-elf.h. There is the dynamic linker of uClibc (/lib/ld-uClibc.so.0) used as well. Maybe it is more reasonable to use the same definition like in the alpha header file. Also, there is another bug, caused by the undefined funcion or macro LINUX_TARGET_OS_CPP_BUILTINS() in the same file (gcc-4.2.1/gcc/config/alpha/linux-elf.h) line 73, which caused a compilation error in file gcc-4.2.1/gcc/c-cppbuiltin.c line 559: The error was: c-cppbuiltin.o: In function `c_cpp_builtins': path/gcc-4.2.1/gcc/c-cppbuiltin.c:559: undefined reference to `LINUX_TARGET_OS_CPP_BUILTINS' Before I posted this bug, I had a look at the current development tree snapshot (file gcc-4.3-20070803.tar.bz2) and found the same header file. (with minor change in commentaries) The configuration was: configure --prefix=/prefix --build=i686-pc-linuc-gnu --host=i686-pc-linuc-gnu --target=arm-none-uclinux --disable-nls --disable-shared --enable-languages=c --disable-threads --disable-tls --with-sysroot=/prefix/sysroot --with-gnu-as --with-gnu-ld --without-headers If you need further information, please feel free to contact me by email: [EMAIL PROTECTED] Best regards Andreas Gajda -- Summary: LINUX_DYNAMIC_LINKER undefined in gcc- 4.2.1/gcc/config/arm/linux-elf.h Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andreas_gajda at web dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-none-uclinux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33036
[Bug middle-end/33007] [4.3 Regression] builtin lround doesn't work
--- Comment #10 from hjl at lucon dot org 2007-08-09 14:15 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00450.html -- hjl at lucon dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00450.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33007
[Bug fortran/33037] New: TRANSFER intrinsic is context sensitive
When using the transfer intrinsic to convert a character string to an array of
integers, and the string does not fit exactly into the integer array data
block, the resultant integer array is scope dependent, with the same code
giving a different resultant integer array in different subroutines/program
units. Basically, the transfer function is not deterministic in the case where
the source data is smaller than the destination data.
There is a small program below to demonstrate the issue. The integer array is
printed twice, and (on my machine) is different each time. The code producing
the two sets of output is exactly the same, but in the first case the code is
embedded in the main program, and in the other case in a subroutine.
I do not have a copy of the standard, but I cannot imagine that this behavior
is correct. The problem arises even if the destination array is initialized to
zero (as shown in the example).
module DataMod
type Byte
character(len=1) :: singleByte
end type
end module
subroutine sub()
use DataMod
integer :: i(1), intarray(4), j
character(len=15) :: str1
type (Byte) :: bytes(15)
type (Byte) :: byteProt(1)
bytes = transfer('123456789012345', byteProt)
print *, bytes(:)%singleByte
intarray = 0
intarray = transfer(bytes, i)
print *, intarray
end subroutine
program test
use DataMod
integer :: i(1), intarray(4), j
character(len=15) :: str1
type (Byte) :: bytes(15)
type (Byte) :: byteProt(1)
bytes = transfer('123456789012345', byteProt)
print *, bytes(:)%singleByte
intarray = 0
intarray = transfer(bytes, i)
print *, intarray
call sub()
end program
--
Summary: TRANSFER intrinsic is context sensitive
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drewmccormack at mac dot com
GCC build triplet: gcc version 4.3.0 20070511 (experimental)
GCC host triplet: powerpc-apple-darwin8.9.0
GCC target triplet: powerpc-apple-darwin8.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug libfortran/33038] New: Unsatisfied symbol lroundl in file libgfortran.sl
/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ /test/gnu/gcc/gcc/gcc/testsui te/gfortran.dg/PR19754_2.f90 -O1 -pedantic-errors -L/test/gnu/gcc/objdir/hp pa64-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11 /./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa64-hp-hpux11.11/./libiberty -lm -o ./PR19754_2.exe(timeout = 300) ld: (Warning) Unsatisfied symbol lroundl in file /test/gnu/gcc/objdir/hppa64-h p-hpux11.11/./libgfortran/.libs/libgfortran.sl 1 warnings. output is: ld: (Warning) Unsatisfied symbol lroundl in file /test/gnu/gcc/objdir/hppa64-h p-hpux11.11/./libgfortran/.libs/libgfortran.sl 1 warnings. FAIL: gfortran.dg/PR19754_2.f90 -O1 (test for excess errors) I see in the build log: checking for lroundl in -lm... no -- Summary: Unsatisfied symbol lroundl in file libgfortran.sl Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa64-hp-hpux11.11 GCC host triplet: hppa64-hp-hpux11.11 GCC target triplet: hppa64-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug bootstrap/33031] Bootstrap fails on gcc/tree.c
--- Comment #2 from matz at gcc dot gnu dot org 2007-08-09 15:50 --- Fixed with my checkin of rev 127316. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33031
[Bug fortran/33037] TRANSFER intrinsic is context sensitive
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 15:50 --- Could you please tell us your gfortran version? (gfortran -v, the gcc-version line is of most interest.) Not that TRANSFER is free of bugs, but it produces here 4.3.0 20070808 (x86_64-unknown-linux-gnu) the same result as NAG f95. NAG f95 warns: Warning: a.f90, line 17: Intrinsic TRANSFER has partly undefined result Warning: a.f90, line 32: Intrinsic TRANSFER has partly undefined result If one runs valgrind on the a.out as produced by gfortran (-m64; no errors shown for -m32): ==21023== Conditional jump or move depends on uninitialised value(s) ==21023==at 0x4E3DD77: _gfortrani_gfc_itoa (error.c:138) ==21023==by 0x4EC0AA3: write_integer (write.c:1343) ==21023==by 0x4EC2BCA: _gfortrani_list_formatted_write (write.c:1541) ==21023==by 0x4EBA76A: _gfortran_transfer_array (transfer.c:1513) ==21023==by 0x40138E: MAIN__ (in /dev/shm/a.out) ==21023==by 0x4013DB: main (fmain.c:22) (and some more of these kind). [Actually, g95 has a similar valgrind output; for NAG f95, ifort and openf95 valgrind finds no error.] This PR could be related to PR 31610. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug fortran/33037] TRANSFER intrinsic is context sensitive
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-09 15:59 --- This is undefined code, when I rewrote most of the transfer code for scalars, I had asked what happens when the sizes did not match and everyone I asked said it was undefined behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug c++/32984] add checking for array new delete
--- Comment #9 from dcb314 at hotmail dot com 2007-08-09 16:03 --- (In reply to comment #8) I suggest taking a technique from the STL and using an auto_array class In practice, I find both STL and Boost are rarely used. Such advanced tools are fine for experienced C++ programmers. For ex-Fortran programmers, new to C++, making their first steps in C++ manual memory management, the news that the C++ compiler will silently eat certainly wrong code is worrying. Hence my bug report. Some newbie C++ programmers need more hand-holding than traditional C++ compilers provide. And as C++ becomes more and more mainstream, this will be more and more true. The bug report remains at resolved wontfix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32984
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #6 from andreasmeier80 at gmx dot de 2007-08-09 16:07 --- It worked well with r126947, but did not with r126951 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug fortran/33039] New: Read NAMELIST: reads wrong namelist name
This has probably already been submitted by Daniel Franke or Jerry DeLisle. I am just trying to see if I can work this system. FORTRAN NAMELIST Run Time Problem The FORTRAN statement READ(5, nml=CODE) should read through the input file (connected to device number 5) until it finds a namelist with the name 'CODE', and then read/process that one namelist. On the next call to this read statement, the program should read further into the input file to find the next occurrence of the name 'CODE'. This was the behaviour from the IBM and HP FORTRAN 77 compilers. It is also the behaviour from the open source g77 compiler. A namelist with name 'CODEone', 'CODEtwo', or 'CODEx' is treated as having a different name, on the basis that the name ends at the trailing 'space' delimiter. A gfortran compiled program appears to read these names and conclude that since the first four letters match the requested name 'CODE', it has found the requested namelist. The program then treats the remaining letters in the name as a variable name and complains that 'one' and 'two' are not defined variables for this namelist. In the case of reading the name 'CODEx', the gfortran program treats the x as a variable name that it recognizes as a valid variable, but complains that it is not followed by an equal sign. It appears that the compiled program needs to read the whole namelist name (up to the delimiting space) and then ask if this name matches the request in the READ statement. I include a short FORTRAN program 'namelist.f' that illustrates the problem when used with the supplied input file 'namelist.in' . The annotated output file 'namelist.out' gives the output (with errors) I found using gfortran and g77 compilers. The problem occurs using gcc-gfortran - 4.1.2-13.fc6.x86_64 libgfortran - 4.1.2-13.fc6.x86_64 running under Linux (Red Hat Fedora Core 6) and gcc-gfortran - 4.1.2-12.i386 libgfortran - 4.1.2-12.i386 running under Linux (Red Hat Fedora Core 7). Victor J. Slabinski C1*2*3*4*5*6*7** C Test of namelist operation in Linux gfortran compiled program: C Does the namelist read skip over namelists with other names or C similar names? namelist.f PROGRAM namelist CHARACTER*25 CHAR NAMELIST /CODE/ CHAR, X NAMELIST /CODEtwo/ X C OPEN(5, file='namelist.in') 100 CHAR = 'Initialize string ***' X= -777. READ(5, nml=CODE, END=999) WRITE(6,*) CHAR, X GO TO 100 999 Itest = 95 write(6,*) 'Itest=',Itest call exit(Itest) STOP 'namelist' END PROGRAM namelist File namelist.in with test NAMELIST inputs CODVJS char='VJS-Not a proper nml name', X=-0.5/ CODEone char='CODEone input', X=-1.0 / CODEtwo char='CODEtwo inputs', X=-2.0/ codechar='Improper lower case name',X=-3.0/ CODEchar='Desired namelist sel', X=44./ CODEx char='Should not read CODEx nml', X=-5./ $CODEchar='Second desired nml', X=66.0 / $CODEX=77.0, char='Reordered desired nml'/ ** Program output from NAMELIST reads with added, interpretive comments; call on FORTRAN compiler also listed. namelist.out ** FORTRAN compiler call: gfortran namelist.f -o namelist Output from executing program 'namelist': Cannot match namelist object name one !variable name 'one' is actually part of nml name CODEone CODEone input -1.00 !output for namelist read that should not have occurred Cannot match namelist object name two !variable name 'two' is actually part of nml name CODEtwo CODEtwo inputs -2.00 !output for namelist read that should not have occurred Improper lower case name -3.00 !shows that nml name upper/lower case does not matter Desired namelist sel44.0 Equal sign must follow namelist object name x !variable name 'x' is actually part of nml name CODEx Cannot match namelist object name har !words in nml string namelist read: missplaced = sign !variable are now Cannot match namelist object name should !treated as variable Cannot match namelist object name not !names Cannot match namelist object name read Cannot match namelist object name codex Cannot match namelist object name nml', Initialize string *** -5.00 !output for namelist read that should not have
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #7 from sje at cup dot hp dot com 2007-08-09 17:02 --- Created an attachment (id=14047) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14047action=view) untested patch I can't reliably reproduce the problem but the attached patch may fix it. It removes the sort and replaces bsearch with a simple linear search. While bootstrapping the largest size I saw for the queue was 7. While compiling larger C++ tests (SPEC2006) I saw it reach 30, but that is the largest I saw. For 30 elements or less (99% of the time it is a single element) I think a linear search is reasonable. Can someone who can reliably reproduce the problem test this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug libffi/28313] libffi has not been ported to mips64-linux-gnu
--- Comment #3 from daney at gcc dot gnu dot org 2007-08-09 17:06 --- I will commit n32/n64 support shortly. -- daney at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |daney at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-07-08 14:28:04 |2007-08-09 17:06:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28313
[Bug target/31325] gcj support for ARM EABI
--- Comment #21 from aph at gcc dot gnu dot org 2007-08-09 17:44 --- I've created abranch for this work at svn+ssh://gcc.gnu.org/svn/gcc/branches/gcj/gcj-eabi-branch It's mostly done, but there are still some bugs. I'll post the patches to the gcc list when they're in a fit state. -- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-03-23 19:32:20 |2007-08-09 17:44:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31325
[Bug libfortran/33038] Unsatisfied symbol lroundl in file libgfortran.sl
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09 17:57 --- Subject: Re: New: Unsatisfied symbol lroundl in file libgfortran.sl The symbol is from misc_specifics.o. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug java/33018] Not able to get past this error
--- Comment #5 from tromey at gcc dot gnu dot org 2007-08-09 18:05 --- See comment #3. The installation manual explains the correct way to configure and build. I'm closing this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33018
[Bug java/33023] throw null
--- Comment #1 from tromey at gcc dot gnu dot org 2007-08-09 18:07 --- Yup, it's a bug. We aren't really fixing bugs in the old front end though. I'm closing it because this is a weird case and has a couple simple workarounds. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33023
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 18:39 --- I think this is a duplicate of PR 33019. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
[Bug libfortran/33038] Unsatisfied symbol lroundl in file libgfortran.sl
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-09 18:41 --- http://gcc.gnu.org/ml/fortran/2007-08/msg00119.html http://gcc.gnu.org/ml/fortran/2007-08/msg00122.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug libfortran/33038] Unsatisfied symbol lroundl in file libgfortran.sl
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-09 18:41 --- Subject: Re: New: Unsatisfied symbol lroundl in file libgfortran.sl The symbol is from misc_specifics.o. It looks like lroundl there is an implementation using roundl. There is an implementation of roundl using ceill, but ceill isn't available. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug fortran/33037] TRANSFER intrinsic is context sensitive
--- Comment #3 from burnus at gcc dot gnu dot org 2007-08-09 18:54 --- This is undefined code, when I rewrote most of the transfer code for scalars, I had asked what happens when the sizes did not match and everyone I asked said it was undefined behavior. Well, nonetheless gfortran could be that kind to follow NAG f95 and print Intrinsic TRANSFER has partly undefined result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug libfortran/32989] getarg and -fdefault-integer-8
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-08-09 19:14 --- Right now, I'd rather work on something else. Unassigning myself (for now, at least). -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tkoenig at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32989
[Bug fortran/32860] Support %ld (for long) for gfc_warning
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-08-06 23:46:07 |2007-08-09 19:22:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32860
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #8 from andreasmeier80 at gmx dot de 2007-08-09 19:24 --- The regression was caused by the following patch New Revision: 126951 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126951 Log: 2007-07-26 Richard Guenther [EMAIL PROTECTED] toplev/ * configure.ac: Add types checking to stage1 checking flags. * configure: Regenerate. gcc/ * tree-cfg.c (verify_gimple_unary_expr, verify_gimple_binary_expr, verify_gimple_min_lval, verify_gimple_reference, verify_gimple_expr, verify_gimple_modify_stmt, verify_gimple_stmt, verify_gimple_1, verify_gimple): New functions. * tree-flow.h (verify_gimple): Declare. (verify_gimple_1): Declare. * gimplify.c (cpt_same_type): Remove. (gimplify_addr_expr): Remove checking code. (check_pointer_types_r): Remove. (gimplify_body): Call verify_gimple_1 instead of check_pointer_types_r. Only verify if there were no errors. * configure.ac: Add types checking flag. * configure: Regenerate. * config.in: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/gimplify.c trunk/gcc/tree-cfg.c trunk/gcc/tree-flow.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug tree-optimization/32941] [4.3 regression] Bootstrap comparison failure
--- Comment #9 from andreasmeier80 at gmx dot de 2007-08-09 19:33 --- I'm now testing the patch from Comment #7. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32941
[Bug fortran/33040] New: ICE in gfc_trans_structure_assign
The following reduced example, based on http://www.lrz-muenchen.de/services/software/mathematik/gsl/fortran/, gives an segmentation fault: fgsl.f90: In function 'fgsl_multifit_fdfsolver_jac': fgsl.f90:24: internal compiler error: Segmentation fault valgrind shows: ==21413== Invalid read of size 2 ==21413==at 0x49810A: gfc_trans_structure_assign (trans-expr.c:3179) tmp = build3 (COMPONENT_REF, TREE_TYPE (field), dest, field, NULL_TREE); ==21413==by 0x497FF3: gfc_trans_subcomponent_assign (trans-expr.c:3139) ==21413==by 0x498142: gfc_trans_structure_assign (trans-expr.c:3180) ==21413==by 0x4982FE: gfc_conv_structure (trans-expr.c:3207) ==21413==by 0x494EA0: gfc_trans_assignment_1 (trans-expr.c:4020) ==21413==by 0x49501B: gfc_trans_assignment (trans-expr.c:4171) ==21413==by 0x4791CA: gfc_trans_code (trans.c:577) The crash occurs because field = NULL, which fails when using TREE_TYPE(field). module fgsl use, intrinsic :: iso_c_binding implicit none type, public :: fgsl_matrix private type(c_ptr) :: gsl_matrix = c_null_ptr end type fgsl_matrix type, public :: fgsl_multifit_fdfsolver private type(c_ptr) :: gsl_multifit_fdfsolver = c_null_ptr end type fgsl_multifit_fdfsolver interface function gsl_multifit_fdfsolver_jac(s) bind(c) import :: c_ptr type(c_ptr), value :: s type(c_ptr) :: gsl_multifit_fdfsolver_jac end function gsl_multifit_fdfsolver_jac end interface contains function fgsl_multifit_fdfsolver_jac(s) type(fgsl_multifit_fdfsolver), intent(in) :: s type(fgsl_matrix) :: fgsl_multifit_fdfsolver_jac fgsl_multifit_fdfsolver_jac%gsl_matrix = gsl_multifit_fdfsolver_jac(s%gsl_multifit_fdfsolver) end function fgsl_multifit_fdfsolver_jac end module fgsl -- Summary: ICE in gfc_trans_structure_assign Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33040
[Bug fortran/33001] error with hexadecimal DATA
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-09 21:28 --- Subject: Bug 33001 Author: burnus Date: Thu Aug 9 21:27:52 2007 New Revision: 127321 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127321 Log: 2007-08-09 Tobias Burnus [EMAIL PROTECTED] PR fortran/33001 * arith.c (arith_error): Point in the error message to -fno-range-check. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33001
[Bug middle-end/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-09 21:37 --- Subject: Bug 32813 Author: pinskia Date: Thu Aug 9 21:36:27 2007 New Revision: 127322 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127322 Log: 2007-08-09 Andrew Pinski [EMAIL PROTECTED] PR middle-end/32813 * fold-const.c (omit_one_operand): Return only the ommitted expression if the result is an empty statement. (pedantic_omit_one_operand): Likewise. 2007-08-09 Andrew Pinski [EMAIL PROTECTED] PR middle-end/32813 * gfortran.fortran-torture/compile/emptyif-1.f90: New test. * lib/fortran-torture.exp (fortran-torture): Use TORTURE_OPTIONS instead of just -O. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/emptyif-1.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/fortran-torture.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug c/32796] [4.3 Regression] internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-09 21:39 --- Subject: Bug 32796 Author: pinskia Date: Thu Aug 9 21:39:08 2007 New Revision: 127323 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127323 Log: 2007-08-09 Andrew Pinski [EMAIL PROTECTED] PR c/32796 * c-typeck.c (build_binary_op): Check for non pointer types before calling int_fits_type_p. 2007-08-09 Andrew Pinski [EMAIL PROTECTED] PR c/32796 * gcc.c-torture/compile/pr32796.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr32796.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug middle-end/32813] [4.3 Regression] ICE for array expression in empty if statement, compiled with -fbounds-check
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-08-09 21:39 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32813
[Bug c/32796] [4.3 Regression] internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-08-09 21:40 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug fortran/33020] Bind(C): c_f_pointer: type/rank mismatch error with integer(8) SHAPE
--- Comment #2 from patchapp at dberlin dot org 2007-08-09 21:45 --- Subject: Bug number PR 33020 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00604.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33020
[Bug libfortran/33038] Unsatisfied symbol lroundl in file libgfortran.sl
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:51 --- (In reply to comment #3) It looks like lroundl there is an implementation using roundl. There is an implementation of roundl using ceill, but ceill isn't available. This has been fixed since, sorry for the breakage. I've just build a hppa2.0w-hp-hpux11.31 compiler since, and it works OK. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33038
[Bug fortran/31832] FAIL: gfortran.dg/integer_exponentiation_2.f90 at -O1 and above
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:54 --- (In reply to comment #1) I have looked into this bug and I think it is an HP math lib bug. The 64 bit powf function is using %fr12R but not saving/restoring it the way it is supposed to. I have a query in to the math lib folks to see if they can verify my finding. Any results? I cannot reproduce this on hppa2.0w-hp-hpux11.31 (neither the original bug nor your testcase that gives different results depending on optimization level). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|fxcoudert at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31832
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:56 --- Still can't reproduce this on hppa2.0w-hp-hpux11.31. I'm starting to think that printf might be broken there, after all. Since it's a corner case on a platform that is not the current one, I'd like to close it as WONTFIX, John, what do you think? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug fortran/32860] Support %ld (for long) for gfc_warning
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:58 --- The patch in the previous comment wasn't even building, here is a one that regtests and that I submitted to review. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00605.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32860
[Bug fortran/32987] TAB in FORMAT: accept extension, warn with -std=f*
--- Comment #8 from burnus at gcc dot gnu dot org 2007-08-09 22:03 --- Subject: Bug 32987 Author: burnus Date: Thu Aug 9 22:02:32 2007 New Revision: 127324 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127324 Log: 2007-08-09 Tobias Burnus [EMAIL PROTECTED] PR fortran/32987 * io.c (format_token): Add FMT_ERROR. (next_char_not_space): Print error/warning when '\t' are used in format specifications. (format_lex): Propagate error. (check_format): Ditto. 2007-08-09 Tobias Burnus [EMAIL PROTECTED] PR fortran/32987 * io/format.c (next_char): Treat '\t' as ' ' in format specification. 2007-08-09 Tobias Burnus [EMAIL PROTECTED] PR fortran/32987 * gfortran.dg/fmt_tab_1.f90: New. * gfortran.dg/fmt_tab_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/fmt_tab_1.f90 trunk/gcc/testsuite/gfortran.dg/fmt_tab_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
[Bug fortran/32987] TAB in FORMAT: accept extension, warn with -std=f*
--- Comment #9 from burnus at gcc dot gnu dot org 2007-08-09 22:08 --- FIXED for gfortran 4.3.0; gfortran now accepts the tab; it checks also at compile time for the tab character and gives either a warning (-std=gnu/legacy) or an error (-std=f95/f2003) if a tab has been found. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32987
[Bug fortran/31629] option to make module entities PRIVATE by default
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-09 22:20 --- Patch submitted for review. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||08/msg00607.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug fortran/31629] option to make module entities PRIVATE by default
--- Comment #4 from patchapp at dberlin dot org 2007-08-09 22:20 --- Subject: Bug number PR 31629 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-08/msg00607.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug fortran/33040] ICE in gfc_trans_structure_assign
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-09 22:23 ---
Some more debugging - I modified gfc_trans_structure_assign to:
--
cm = expr-ts.derived-components; i = 1;
for (c = expr-value.constructor; c; c = c-next, cm = cm-next)
{
printf(DEBUG: gfc_trans_structure_assign, loop %i; cm-name = %s\n,i++,
cm-name);
if (!c-expr)
continue;
field = cm-backend_decl;
if (field == NULL) {
gfc_error (field is zero at %L, c-expr-where); continue;
}
--
DEBUG: gfc_trans_structure_assign, loop 1; cm-name = __c_ptr_c_address
fgsl.f90:2.33:
use, intrinsic :: iso_c_binding
1
Error: field is zero at (1)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||crickett at lanl dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33040
[Bug fortran/33037] TRANSFER should warn on mismatched sizes
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2007-08-09 22:58:12 date|| Summary|TRANSFER intrinsic is |TRANSFER should warn on |context sensitive |mismatched sizes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33037
[Bug fortran/33040] [ISO_C_BINDING] ICE in gfc_trans_structure_assign
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||32630 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-09 22:54:15 date|| Summary|ICE in |[ISO_C_BINDING] ICE in |gfc_trans_structure_assign |gfc_trans_structure_assign http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33040
[Bug fortran/31822] Missing run-time bound checks for character pointer = target
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-09 22:52:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31822
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-08-09 23:27
---
Regarding the test case:
codechar='Improper lower case name',X=-3.0/
Fortran 95 Standard 10.9.1 states:
If a processor is capable of representing letters in both upper and lower
case, a group name or object name is without regard to case.
So lower case is not improper.
The standard also states that at least one space is required after the namelist
name. This patch fixes it:
Index: list_read.c
===
--- list_read.c (revision 127265)
+++ list_read.c (working copy)
@@ -2592,6 +2592,13 @@ find_nml_name:
if (dtp-u.p.nml_read_error)
goto find_nml_name;
+
+ c = next_char (dtp);
+ if (c != ' ')
+{
+ unget_char (dtp, c);
+ goto find_nml_name;
+}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
[Bug fortran/33020] Bind(C): c_f_pointer: type/rank mismatch error with integer(8) SHAPE
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-08-09 23:04:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33020
[Bug c/22371] C front-end produces mis-match types in MODIFY_EXPR
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-08-09 23:39 --- Created an attachment (id=14048) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14048action=view) Candidate patch from 2005 Here's my patch from 2005 as requested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22371
[Bug fortran/33039] Read NAMELIST: reads wrong namelist name
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-08-09 23:37 --- *** Bug 33019 has been marked as a duplicate of this bug. *** -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33039
