Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Mark Mitchell <[EMAIL PROTECTED]> writes: | Ian Lance Taylor wrote: | | > I realized that I am still not stating my position very clearly. I | > don't think we should make any extra effort to make this code work: | > after all, the code is undefined. I just think 1) we should not | > insert a trap; 2) we should not ICE. | | I agree. If the inlining thing is indeed a problem (and I can see how | it could be, even though you could not immediately reproduce it), then | we should mark the call as uninlinable. Disabling an optimization in | the face of such a cast seems more user-friendly than inserting a trap. | Since we know the code is undefined, we're not pessimizing correct | code, so this is not a case where to support old code we'd be holding | back performance for valid code. | | I also agree with Gaby that we should document this as an extension. If | we go to the work of putting it back in, we should ensure that it | continues to work for the foreseeable future. Part of that is writing | down what we've decided. The collection of both points captures my inclination on this matter. -- Gaby
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Mark Mitchell writes: > > I also agree with Gaby that we should document this as an extension. If > we go to the work of putting it back in, we should ensure that it > continues to work for the foreseeable future. Part of that is writing > down what we've decided. We can't make function pointer type casts work in the general case, as we know; all we can promise to do is make our best effort. How can we document that? I suppose we could say that it should work as long as the types of the parameters of the two functions are compatible, but not otherwise. Andrew.
Re: A question about TYPE_ARG_TYPES
That may be the difference between "void f()" (where TYPE_ARG_TYPES
might be NULL) and "void f(...)" (where TREE_VALUE (TYPE_ARG_TYPES)
would be NULL). The latter, as Daniel says, is not valid C, but perhaps
we used to accept it.
"void f(...)" is how you refer to an old-style function definition in a
C++ `extern "C"' block. That is,
extern "C" void f1(...);
extern "C" void f2();
void g()
{
f1(5);
f2(5);
}
the call to f1 is valid and the one to f2 is not. I haven't check what
TYPE_ARG_TYPES is in these cases.
Paolo
Re: RFA: new execute testcase (Was: Re: bootstrap failed during 'make check')
Joern Rennecke wrote:
Andrew Haley wrote:
> > So it seems I have to abandom the system compiler for doing
bootstraps.
Can you make a simple testcase for this?
Andrew.
Attached.
This fails at -O0..-O2 for gcc 3.2.2 and gcc 3.2.3 on
i686-pc-linux-gnu. For gcc 3.4.3,
it still fails at -O1.
4.2.0 appears to be OK, although it might be this bug only hidden by
the tree optimizers
optimizing the test case into something that doesn't trigger the bug.
I've identified this code in 3.4.0 c-typeck.c:common_type as the culprit:
case POINTER_TYPE:
/* For two pointers, do this recursively on the target type,
and combine the qualifiers of the two types' targets. */
/* This code was turned off; I don't know why.
But ANSI C specifies doing this with the qualifiers.
So I turned it on again. */
{
tree pointed_to_1 = TREE_TYPE (t1);
tree pointed_to_2 = TREE_TYPE (t2);
tree target = common_type (TYPE_MAIN_VARIANT (pointed_to_1),
TYPE_MAIN_VARIANT (pointed_to_2));
t1 = build_pointer_type (c_build_qualified_type
(target,
TYPE_QUALS (pointed_to_1) |
TYPE_QUALS (pointed_to_2)));
return build_type_attribute_variant (t1, attributes);
}
(gdb) s
325 TYPE_QUALS (pointed_to_2)));
(gdb)
c_build_qualified_type (type=0xb5988804, type_quals=1)
at ../../srcw/gcc/c-common.c:2793
2793 if (type == error_mark_node)
(gdb) call debug_tree(type)
unit size
align 32 symtab 0 alias set -1 precision 32 min 0xb599a26c -2147483648> max
pointer_to_this >
DI
size bit_size_type> constant 64>
unit size unsigned int> constant 8>
align 64 symtab 0 alias set -1
arg-types
chain >>
pointer_to_this >
One of the function pointers is TREE_READONLY, and we make the result
TREE_READONLY.
This is wrong, since TREE_READONLY for functions means that they have no
side effects.
There is similar code in mainline, but it is not reached with the testcase.
Re: dejaGNU testsuite files for 2.95.3 20010315 (release)
J.J.Garcia wrote: I'm messed with this, anyway i don't understand why the 2.95.3 doesn't have a testsuite folder within. Because gcc had no official testsuite at that time, so obviously, there was no testsuite folder (directory). We did have a package called c-torture that was released separately from gcc, which included the beginnings of a regression testsuite. It was eventually added to gcc after resolving some copyright issues, and formed the core of what is now the gcc testsuite. You might be able to find a 8 year old copy if you google for it. I don't know offhand where to find a copy. It is an oversight that we didn't archive a copy of it on our ftp server. There was a period during which c-torture was in the FSF GCC development tree, but not part of the gcc releases. I suspect gcc-2.95 was during this period. The cvs/svn tree might be a little confused during this period, as the testsuite dir might be on mainline, but not on release branches. Or it might be on release branches but not in release tarballs. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: request of copyright assignment form
Daniel Franke wrote: HI all. Could someone please send me the "copyright assignment form"? Please see the form in http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html One of these days I will have to put this into the wiki. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
GCC dejagnu testsuite: how to check for non-zero exit code?
I'd like to include cases in the gfortran testsuite to check that we
correctly issue a run-time error, and exit with non-zero code.
I have the following example:
$ cat runtime_error.f90
! { dg-do run }
! { dg-options "-fbounds-check" }
integer :: x(5), y(5)
x = y((/0,2,3,4,6/))
end
$ gfortran runtime_error.f90 -fbounds-check
$ ./a.out ; echo $?
Fortran runtime error: Array reference out of bounds for array 'y',
lower bound of dimension 1 exceeded (in file 'runtime_error.f90', at line 4)
2
I'd like to be able to check that this code indeed issue the error
message on stderr and indicate to dejagnu that non-zero exit codes does
not mean that the test FAILed). How can I do that?
Thanks for any help,
FX
Addressing modes question
Hi, Is it possible for me to write a backend that accepts certain addressing modes for loads, while rejecting them for stores? I am not sure how to do this with the GO_IF_LEGITIMATE_ADDRESS macro. I know that this is not very sane, but the situation has arisen neverthless. I want to allow only indexed addressing on stores, while allowing immediate forms of addressing with loads. Any help is much appreciated. thanks, Matt
coercion warnings for NULL in C front end
Dear all,
Once the implementation of warnings for coercions that may change a
value in the simplest cases is roughly completed [1], I am starting to
consider other possible cases. As an example, the C++ front end given
the Wconversion option currently emits a warning for:
int i = NULL;
Would it be appropriate for the C front end to copy C++ handling of
NULL with regards to -Wconversion ? A more complete testcase can be
found at the end of the message and in the Wcoercion page [2].
Cheers,
Manuel.
[1] http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00098.html
[2] http://gcc.gnu.org/wiki/Wcoercion#NULL
void k(int) {}
int main()
{
int i = NULL; // { dg-warning "" } converting NULL to non-pointer type
float z = NULL; // { dg-warning "" } converting NULL to non-pointer type
int a[2];
i != NULL; // { dg-warning "" } NULL used in arithmetic
NULL != z; // { dg-warning "" } NULL used in arithmetic
k != NULL; // No warning: decay conversion
NULL != a; // Likewise.
-NULL; // { dg-warning "" } converting NULL to non-pointer type
+NULL; // { dg-warning "" } converting NULL to non-pointer type
~NULL; // { dg-warning "" } converting NULL to non-pointer type
a[NULL] = 3; // { dg-warning "" } converting NULL to non-pointer-type
i = NULL; // { dg-warning "" } converting NULL to non-pointer type
z = NULL; // { dg-warning "" } converting NULL to non-pointer type
k(NULL); // { dg-warning "" } converting NULL to int
NULL && NULL; // No warning: converting NULL to bool is OK
}
Re: Addressing modes question
"Matt Lee" <[EMAIL PROTECTED]> writes: > Is it possible for me to write a backend that accepts certain > addressing modes for loads, while rejecting them for stores? I am not > sure how to do this with the GO_IF_LEGITIMATE_ADDRESS macro. I know > that this is not very sane, but the situation has arisen neverthless. > I want to allow only indexed addressing on stores, while allowing > immediate forms of addressing with loads. As far as I know there is no good way to do with the current infrastructure. Certainly GO_IF_LEGITIMATE_ADDRESS won't help. The best I know how to do is use different constraint characters for loads and stores, and recognize them differently in the insn patterns. You will want the movsi (or whatever) expander to pick the right forms. The main drawback with this approach is that you can land in reload hell, from which I believe the only escape is to implement appropriate secondary reloads for hideous screwed up conditions. I was able to get something similar working for a DSP backend I implemented, Ian
gcc-4.0-20060706 is now available
Snapshot gcc-4.0-20060706 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060706/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 115232 You'll find: gcc-4.0-20060706.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20060706.tar.bz2 C front end and core compiler gcc-ada-4.0-20060706.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20060706.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20060706.tar.bz2 C++ front end and runtime gcc-java-4.0-20060706.tar.bz2 Java front end and runtime gcc-objc-4.0-20060706.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20060706.tar.bz2The GCC testsuite Diffs from 4.0-20060629 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Addressing modes question
On Thu, 2006-07-06 at 15:08 -0700, Ian Lance Taylor wrote: > "Matt Lee" <[EMAIL PROTECTED]> writes: > > > Is it possible for me to write a backend that accepts certain > > addressing modes for loads, while rejecting them for stores? I am not > > sure how to do this with the GO_IF_LEGITIMATE_ADDRESS macro. I know > > that this is not very sane, but the situation has arisen neverthless. > > I want to allow only indexed addressing on stores, while allowing > > immediate forms of addressing with loads. > > As far as I know there is no good way to do with the current > infrastructure. Certainly GO_IF_LEGITIMATE_ADDRESS won't help. Correct. > The best I know how to do is use different constraint characters for > loads and stores, and recognize them differently in the insn patterns. > You will want the movsi (or whatever) expander to pick the right > forms. The main drawback with this approach is that you can land in > reload hell, from which I believe the only escape is to implement > appropriate secondary reloads for hideous screwed up conditions. I > was able to get something similar working for a DSP backend I > implemented, You might want to look at the PA backend. Some of its addressing mode quirks: 1. Integer indexed loads, but no integer indexed stores. 2. FP indexed loads and stores. 3. Integer reg+d addresses allow a larger "d" than FP reg+d addresses. 4. Segmented adress space where the segment is selected using bits in the base register only (not the effective address). This implies you must distinguish between the base and index register in unscaled indexing address modes (if you get it wrong, then you get a segfault for accessing the wrong segment). And finally, the PA implementes integer multiplication in FP registers, so it is fairly common to have SI/DImode memory operations to/from FP registers. So legitimacy of an address can't 100% reliably be keyed to the mode of the memory op. It was a living hell trying to get good code from GCC with such a mucked up addressing model. jeff
Re: coercion warnings for NULL in C front end
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| int main()
| {
| int i = NULL; // { dg-warning "" } converting NULL to non-pointer type
In many C implementations, NULL is defined as
#define NULL ((void *) 0)
which renders the above initialization ill-formed -- not just a warning.
-- Gaby
Different invariants about the contents of static links
The following example C code and disassembly is compiled by gcc 3.4.3,
for i686. It uses two different invariants for what the value of
a static link is. Everywhere inside P, static link values are consistently
the same as base pointer (%ebp) register values for the same activation
record. A static link value is generated at 4c: in P, and used at
22: in PInner2 and c: in PInner1.
Everywhere inside similar function Q, static link values consistently point
8 bytes higher than where the base register points. A value is generated at
d9: in Q and used at 7a: in Qinner2 and 64: in QInner1.
From the examples I have looked at, it looks like it is correct translation,
and, expect for seeming strangeness, is not a problem for execution.
However, I am working on an extended gdb-derived debugger that works,
in part, with code produced by a gcc-derived code generator for
Modula-3. So far, I can't find out, in the debugger, which invariant
is in use. I have the debugger correctly both generating and using
static links when evaluating user-typed expressions, using the first
invariant. I could easily change it to use the second invariant, but
obviously, that would fix some cases and break others.
Is there a compelling reason for this difference? If not, I would like to
make it all use invariant one. Also, does anybody know where in gcc this
difference is happening? I poked around in the source for a couple of hours,
but didn't see anything obvious.
BTW, this is using stabs. I know that is not very complete, but it would be
a lot more work than I want to do to change it.
-
typedef int ( * PFuncT ) ( int F );
int G2;
int P ( int PF )
{ int PInner1 ( int PInner1F )
{ return PF + PInner1F;
} /* PInner1 */
int PInner2 ( int PInner2F )
{ G2 = PF;
return PInner1 ( PInner2F );
} /* PInner2 */
return PInner2 ( PF + 3 );
} /* P */
int Q ( int QF )
{ int QInner1 ( int QInner1F )
{ return QF + QInner1F;
} /* QInner1 */
int QInner2 ( int QInner2F, PFuncT QInner2FProc )
{ G2 = QF;
return QInner2FProc ( QInner2F );
} /* QInner2 */
return QInner2 ( QF + 3 , QInner1 );
} /* Q */
int main ( )
{ P ( 33 );
Q ( 13 );
} /* main */
--
StaticStrange2.o: file format elf32-i386
Disassembly of section .text:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 83 ec 04sub$0x4,%esp
6: 89 4d fcmov%ecx,0xfffc(%ebp)
9: 8b 4d fcmov0xfffc(%ebp),%ecx
c: 8b 51 fcmov0xfffc(%ecx),%edx
f: 8b 45 08mov0x8(%ebp),%eax
12: 03 02 add(%edx),%eax
14: c9 leave
15: c3 ret
0016 :
16: 55 push %ebp
17: 89 e5 mov%esp,%ebp
19: 83 ec 04sub$0x4,%esp
1c: 89 4d fcmov%ecx,0xfffc(%ebp)
1f: 8b 4d fcmov0xfffc(%ebp),%ecx
22: 8b 41 fcmov0xfffc(%ecx),%eax
25: 8b 00 mov(%eax),%eax
27: a3 00 00 00 00 mov%eax,0x0
2c: ff 75 08pushl 0x8(%ebp)
2f: e8 cc ff ff ff call 0
34: 83 c4 04add$0x4,%esp
37: c9 leave
38: c3 ret
0039 :
39: 55 push %ebp
3a: 89 e5 mov%esp,%ebp
3c: 83 ec 04sub$0x4,%esp
3f: 8d 45 08lea0x8(%ebp),%eax
42: 89 45 fcmov%eax,0xfffc(%ebp)
45: 8b 45 08mov0x8(%ebp),%eax
48: 83 c0 03add$0x3,%eax
4b: 50 push %eax
4c: 89 e9 mov%ebp,%ecx
4e: e8 c3 ff ff ff call 16
53: 83 c4 04add$0x4,%esp
56: c9 leave
57: c3 ret
0058 :
58: 55 push %ebp
59: 89 e5 mov%esp,%ebp
5b: 83 ec 04sub$0x4,%esp
5e: 89 4d fcmov%ecx,0xfffc(%ebp)
61: 8b 4d fcmov0xfffc(%ebp),%ecx
64: 8b 51 fcmov0xfffc(%ecx),%edx
67: 8b 45 08mov0x8(%ebp),%eax
6a: 03 02 add(%edx),%eax
6c: c9 leave
6d: c3 ret
006e :
6e: 55 push %ebp
6f: 89 e5 mov%esp,%ebp
71: 83 ec 08sub$0x8,%esp
74: 89 4d fcmov%ecx,0x
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Andrew Haley wrote: > Mark Mitchell writes: > > > > I also agree with Gaby that we should document this as an extension. If > > we go to the work of putting it back in, we should ensure that it > > continues to work for the foreseeable future. Part of that is writing > > down what we've decided. > > We can't make function pointer type casts work in the general case, as > we know; all we can promise to do is make our best effort. How can we > document that? We can say something like: "In GNU C, you may cast a function pointer of one type to a function pointer of another type. If you use a function pointer to call a function, and the dynamic type of the function pointed to by the function pointer is not the same as indicated by the static type of the function pointer, then the results of the call are unspecified. In general, if the types are not too different (e.g., the dynamic type is "void ()(unsigned int)" while the static type is "void ()(int)"), then the results of the call will probably be as you expect. However, if the types are sufficiently different, there is no guarantee that your program will behave in any predictable fashion." The use of "unspecified" here (as opposed to "undefined") indicates that, while we're not saying what happens, we're also suggesting that this is a more benign issue. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
replace_rtx
Hi, I am doing some modification to gcc's RTL code. I am trying to split a pseudo (old) into two pseudos (old and new) and rewriting some part of the code to replace the "old" pseudo by the "new" pseudo. I am using the "replace_rtx" function to perform the replacement. However I get "fatal error: internal consistency failure" when I try to execute any program. The specific call that I make is: replace_rtx (insn, old_rtx, new_rtx); I notice that "replace_rtx" actually performs the replacement when I try to print the "insn" before and after the call. However, later on I get the error "internal consistency failure". I would like to know what are the cases in which this error is thrown. Is there any document which I can refer to? regards, Raj
