Re: gcc 4.2 more strict check for "function called through a non-compatible type"
> 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. > > It may lead to misunderstanding since standard uses "unspecified behavior" wording with other meaning: when standard provides two or more possibilities and imposes no requirements on which is chosen, i.e. "the order of evaluation of function-call parameters is unspecified". The result of calling function pointer casted to sufficiently different type is a real example an undefined behavior. I suggest to avoid using "unspecified" wording here.
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Yuri Pudgorodsky writes:
>
> > 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
s/not too different/compatible/
"not too different" has no meaning, whereas "compatible" is defined in
Section 6.2.7.
So,
"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 type of any of the arguments to the function being
called is not compatible with the type of the corresponding argument
being passed, then the results of the call are undefined."
We need to do this because we use type-based alias analysis in gcc.
Imagine this scenario:
void poo (type_a *A, type_b *B)
{
...
}
The compiler knows that if types type_a and type_b are incompatible,
they cannot alias, and takes advantage of that fact. So, for example,
references to A and B might be reordered. If we permit incompatible
types to be casted in function calls, we make a hole in alias
analysis.
Imagine this usage:
type_a *A1, *A2;
fptr fun = (fptr)foo;
(*fun)(A1, A1);
Andrew.
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes: [...] | The result of calling function pointer casted to sufficiently different | type is | a real example an undefined behavior. As I said earlier, it is fruitless to try to impose an ordering on the space of undefined behaviour. -- Gaby
In which library is __register_frame_info defined??
Hi I want to use the function __register_frame_info to dynamically register DWARF2 unwind frames. Where is the library I should link with?? Environment: linux 64 bits Thanks in advance Jacob P.S. I have posted some messages here before, concerning this problem. I had to do a long rewriting of the code generator to adapt it better to the style of code used in lcc64. This done, I have figured out the format of the DWARF2 eh_frame stuff, and now I generate that stuff dynamically. Now, the only thing left is to pass it to __register_frame_info.
Re: In which library is __register_frame_info defined??
jacob navia writes: > Hi > > I want to use the function > > __register_frame_info > > to dynamically register DWARF2 unwind frames. > > Where is the library I should link with?? > > Environment: linux 64 bits prefix/lib64/libgcc_s.so.1; but you shouldn't specify this library because gcc always links it. Andrew.
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Gabriel Dos Reis wrote: > Yuri Pudgorodsky <[EMAIL PROTECTED]> writes: > > [...] > > | The result of calling function pointer casted to sufficiently different > | type is > | a real example an undefined behavior. > > As I said earlier, it is fruitless to try to impose an ordering on > the space of undefined behaviour. > > -- Gaby > My whole concern is about the rule for artificially generated trap (turned out to be for an ICE hiding purpose) that has been changed once more in 4.2 and yet the changed rule does not catch all cases. As a result of such old decision, we currently have: - different behavior for different front-ends - may be a real cause is not fixed yet - different developer's "workaround" for <3.3.2, 3.3.2-4.1 and 4.2 compilers - yet there is still a syntax to generate old "undefined-behaviour" function call, so its a straight way for future messy changes (not to mentioned a mess with different frontends behaviour) I can imagine the benefit from -ftrap-on-undefined-behaviour option (seriously speaking -Wundefined-behavior is better). But trapping some syntaxes of the same semantic is just a straight way to confuse developers and is not a well-established practice. It's like trapping "i = i++" expr at the same time leaving traditional undefined behaviour for "i = (i++)". See, currently compiler is able to generate code for assignment cast: double foo(double); int (*bar)(int) = foo; bar (0); Why should it ICE/trap on expression cast? ((int (*)(int)) foo) (0) Nevertheless looks like we already agreed to remove trap generation code because: - it does not not ICE anymore (c, c++ frontend) - it restores "natural" platform-dependent undefined behaviour - it makes legacy code accidentally work (like openssl casts) Just a reminder: objective-c[++] frontend still have an ICE for some casted function pointers and needs to be fixed like c/c++ was already fixed.
Re: gcc 4.2 more strict check for "function called through a non-compatible type"
Yuri Pudgorodsky <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | > Yuri Pudgorodsky <[EMAIL PROTECTED]> writes: | > | > [...] | > | > | The result of calling function pointer casted to sufficiently different | > | type is | > | a real example an undefined behavior. | > | > As I said earlier, it is fruitless to try to impose an ordering on | > the space of undefined behaviour. | > | > -- Gaby | > | My whole concern is about the rule for artificially generated trap | (turned out | to be for an ICE hiding purpose) that has been changed once more in 4.2 | and yet the changed rule does not catch all cases. I believe the consensus has been summarized by Mark. The remaining preoccupation is how we write the documentation. My objection is to an attempt to put an ordering on the space of undefined behaviour as a basis to reject the description "unspecified". And, yes syntax matters. -- Gaby
Re: Addressing modes question
On Thu, Jul 06, 2006 at 02:23:24PM -0700, Matt Lee wrote: > 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. Wanna know what? You're not the first one to ask this question. This has been discussed at least twice recently and the resulting messages are available in the Fine Mailing List Archive. See the threads starting at http://gcc.gnu.org/ml/gcc/2006-05/msg00644.html> (continued at http://gcc.gnu.org/ml/gcc/2006-06/msg00019.html>) and at http://gcc.gnu.org/ml/gcc/2006-06/msg00301.html>. Two different ways of achieving what you want are discussed. It really would be nice to have more information about the memory access available in GO_IF_LEGITIMATE_ADDRESS(), such as the direction (read, write or modify) and the insn (code number?) and operand number in which the memory access occurs. -- Rask Ingemann Lambertsen
Re: Different invariants about the contents of static links
"Rodney M. Bates" <[EMAIL PROTECTED]> writes: > 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. The static link pointer points to a part of the stack frame which includes the information required for the nested functions. The amount of information required changes depending on the code. Therefore, the static link pointer will not be a constant offset from the frame pointer. I don't believe that it is possible to change this while still handling calls between doubly nested functions, but maybe I just haven't thought about it hard enough. > 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. Stabs doesn't represent the static link pointer at all, so that is your problem. You should switch to DWARF. If that is impossible as you suggest, then I think your most profitable approach would be to enhance stabs somehow. Ian
Re: replace_rtx
Rajkishore Barik <[EMAIL PROTECTED]> writes: > 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? Your first step should be to fire up the debugger and find out where the error occurs. That will most likely tell you the kind of thing you need to do to fix it. You neglected to mention where in the compiler you are creating the new pseudo--e.g., which pass. However, the problem is most likely a failure to call reg_scan_update or update_life_info. Ian
Re: request of copyright assignment form
On Jul 6, 2006, at 1:48 PM, Jim Wilson wrote: 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. Added: http://gcc.gnu.org/wiki/Copyright%20assignment Link to it added to: http://gcc.gnu.org/wiki/HomePage seemed like the best place.
Re: GCC dejagnu testsuite: how to check for non-zero exit code?
On Jul 6, 2006, at 1:48 PM, FX Coudert wrote: 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? There are two strategies, first would be to write a driver for it. If you check out *.exp, you can find many examples of drivers, though, none are likely to do just what you want. The second way would be to extend the semantics of an existing driver to do what you want. The downsides to the second approach would be causing a slowdown of the entire rest of the testsuite if done poorly and needing to require a new version of dejagnu, if you had to modify a driver from it. I don't think the existing drivers have a way to do this.
Re: request of copyright assignment form
On Fri, 7 Jul 2006, Mike Stump wrote: > On Jul 6, 2006, at 1:48 PM, Jim Wilson wrote: >> 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. > Added: > > http://gcc.gnu.org/wiki/Copyright%20assignment > > Link to it added to: > > http://gcc.gnu.org/wiki/HomePage > > seemed like the best place. I'm afraid I have to ask you to remove this again. RMS explicitly requested we do not provide this on our web pages, or I would have added it years ago. (Of course referring mailing list archives are not that different, but there is a bit of difference.) Gerald
Re: request of copyright assignment form
On Jul 7, 2006, at 1:38 PM, Gerald Pfeifer wrote: I'm afraid I have to ask you to remove this again. Done.
Re: request of copyright assignment form
On Fri, 2006-07-07 at 13:38, Gerald Pfeifer wrote: > I'm afraid I have to ask you to remove this again. RMS explicitly > requested we do not provide this on our web pages, or I would have > added it years ago. I thought it was the actual legal forms that weren't supposed to be on the web site, but that the questionnaire was OK. The legal forms can't be on the web site because too many people fill them out incorrectly, wasting the FSF's time and money. The questionnaire on the other hand is intended to be filled out by contributors, and should be OK for us to distribute. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
gcc-4.1-20060707 is now available
Snapshot gcc-4.1-20060707 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060707/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 115271 You'll find: gcc-4.1-20060707.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060707.tar.bz2 C front end and core compiler gcc-ada-4.1-20060707.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060707.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060707.tar.bz2 C++ front end and runtime gcc-java-4.1-20060707.tar.bz2 Java front end and runtime gcc-objc-4.1-20060707.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060707.tar.bz2The GCC testsuite Diffs from 4.1-20060630 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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: GCC dejagnu testsuite: how to check for non-zero exit code?
FX Coudert wrote: 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. Try dg-error. There are lots of examples to look at in existing testcases, including in the gfortran.dg directory. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: externs and thread local storage
On Sun, Jul 02, 2006 at 12:23:34PM -0700, Gary Funck wrote: > In my view, this is implementation-defined, and generally can vary > depending upon the underlying linker and OS technology. Further, > there is at least one known platform (IA64) which seems to not impose > this restriction. You're kidding, right? *All* targets have to generate different code for thread-local storage. If it didn't, it wouldn't be thread-local, would it? r~
Re: request of copyright assignment form
> I thought it was the actual legal forms that weren't supposed to be on > the web site, but that the questionnaire was OK. The legal forms can't > be on the web site because too many people fill them out incorrectly, > wasting the FSF's time and money. The questionnaire on the other hand > is intended to be filled out by contributors, and should be OK for us to > distribute. That was my understanding as well.
Re: request of copyright assignment form
On Fri, 7 Jul 2006, James E Wilson wrote: > I thought it was the actual legal forms that weren't supposed to be on > the web site, but that the questionnaire was OK. I believe I recall we were not supposed to have either, but you raise a good point. I will double check this with RMS, and if he agrees, I will make sure to add the questionnaire (and buy Mike a drink next time I meet him). Gerald
Re: request of copyright assignment form
On Jul 7, 2006, at 5:33 PM, Gerald Pfeifer wrote: I believe I recall we were not supposed to have either, but you raise a good point. I will double check this with RMS, and if he agrees, I will make sure to add the questionnaire (and buy Mike a drink next time I meet him). I'd welcome them putting it on _their_ web site, and then just liking to it from ours, and totally dispense with all the cryptic directions we now have. They can then update their web site any time they want, in any way they want, they just have to agree up front to maintaining it forever. This would be better than putting that on our web site.
Re: [PATCH] config/arm/arm.c: Use GOT instead of GOTOFF when XIP
Any comments on this patch? This patch, or something like it, is
absolutely necessary to support execute-in-place (XIP) on uClinux.
Please cc me in your reply. Cheers,
Shaun
On 6/29/06, Shaun Jackman <[EMAIL PROTECTED]> wrote:
This patch forces the use of GOT relocations instead of GOTOFF when
compiling execute-in-place (XIP) code. I've defined XIP as the
combination of -fpic and -msingle-pic-base.
There is room for improvement in using GOTOFF relocations for symbols
that will be in the same addressing space as the GOT (.data likely)
and PC relative relocations for symbols that will be in the same
addressing space as the PC (.text and .rodata likely).
I'm open to suggestions for the name of the new predicate, which I've
named local_symbol_p here. I had named it use_gotoff_p at one point.
Cheers,
Shaun
2006-06-29 Shaun Jackman <[EMAIL PROTECTED]>
* config/arm/arm.c (local_symbol_p): New function.
(legitimize_pic_address, arm_assemble_integer): Use it to prevent
GOTOFF relocations to the .text segment in execute-in-place code.
Index: config/arm/arm.c
===
--- config/arm/arm.c(revision 115074)
+++ config/arm/arm.c(working copy)
@@ -3193,6 +3193,17 @@
return 1;
}
+static int
+local_symbol_p(rtx x)
+{
+ /* Execute-in-place code fails if a GOTOFF relocation is used to
+ * adress a local symbol in the .text segment. */
+ if (flag_pic && TARGET_SINGLE_PIC_BASE)
+return 0;
+ return GET_CODE (x) == LABEL_REF
+|| (GET_CODE (x) == SYMBOL_REF && SYMBOL_REF_LOCAL_P (x));
+}
+
rtx
legitimize_pic_address (rtx orig, enum machine_mode mode, rtx reg)
{
@@ -3271,10 +3282,7 @@
else
emit_insn (gen_pic_load_addr_thumb (address, orig));
- if ((GET_CODE (orig) == LABEL_REF
- || (GET_CODE (orig) == SYMBOL_REF &&
- SYMBOL_REF_LOCAL_P (orig)))
- && NEED_GOT_RELOC)
+ if (NEED_GOT_RELOC && local_symbol_p (orig))
pic_ref = gen_rtx_PLUS (Pmode, cfun->machine->pic_reg, address);
else
{
@@ -11292,12 +11300,10 @@
if (NEED_GOT_RELOC && flag_pic && making_const_table &&
(GET_CODE (x) == SYMBOL_REF || GET_CODE (x) == LABEL_REF))
{
- if (GET_CODE (x) == SYMBOL_REF
- && (CONSTANT_POOL_ADDRESS_P (x)
- || SYMBOL_REF_LOCAL_P (x)))
+ if ((GET_CODE (x) == SYMBOL_REF
+ && CONSTANT_POOL_ADDRESS_P (x))
+ || local_symbol_p (x))
fputs ("(GOTOFF)", asm_out_file);
- else if (GET_CODE (x) == LABEL_REF)
- fputs ("(GOTOFF)", asm_out_file);
else
fputs ("(GOT)", asm_out_file);
}
Re: Visibility and C++ Classes/Templates
Jason Merrill wrote: > Hmm, I'm starting to be convinced that ignoring #pragma visibility for > all template instantiations and specializations will be a simpler rule > for users to understand. I think I argued for that earlier; in any case, I agree. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: In which library is __register_frame_info defined??
On Jul 7, 2006, at 7:14 AM, jacob navia wrote: Where is the library I should link with? nm libgcc_eh.a | grep register_frame 00e4 T ___register_frame_info It is automatically linked with. I think you probably have the wrong number of _ at the front, try removing one. After that, try nm on you .o file and on /usr/lib/*.a and see if the spellings match.
Re: externs and thread local storage
Richard Henderson wrote: On Sun, Jul 02, 2006 at 12:23:34PM -0700, Gary Funck wrote: In my view, this is implementation-defined, and generally can vary depending upon the underlying linker and OS technology. Further, there is at least one known platform (IA64) which seems to not impose this restriction. You're kidding, right? *All* targets have to generate different code for thread-local storage. If it didn't, it wouldn't be thread-local, would it? That's not true, thread local storage can be done simply by mapping hardware on some machines, where you swap maps on a context switch. r~
