Re: [gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call
"Andrew Pinski" <[EMAIL PROTECTED]> writes: > On Jan 30, 2008 7:38 PM, Dongsheng Song <[EMAIL PROTECTED]> wrote: >> See: http://www.linuxonly.nl/docs/2/0_Page_1.html > > It says: > This is because NULL is not of the right type: it is defined as > integer 0 instead of a pointer with the value 0. > > Except that is wrong from what the C99 standard says about the NULL macro: > The macros are > NULL > which expands to an implementation-defined null pointer constant And 0 is a valid null pointer constant. > So no casting is needed as it is already a pointer type if we follow > the C99 standard (I think C90 says the same thing except I don't have > C90 in front of me). A null pointer constant is _not_ a pointer. It is only becomes a pointer when explicitly or implicitly converted to one. Neither is the case here. 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."
Inserting NOP instructions and branch delay slots
Hi! I have to insert NOP-instructions into the insn-stream in my back- end. I do this with something ala emit_insn_after(gen_nop, xyz). This works so far. GCC leaves control-flow operations as they are, if it there are no instructions which can be used to fill the branch delay slots. My first idea was to convert these control-flow cf to SEQUENCE(cf) and hope the GCC will invoke DBR_OUTPUT_SEQEND(), but it does not? My second idea was to add these NOP-instructions: SEQUENCE(cf, NOP,...,NOP). I "reused" the code in function emit_delay_sequence() in reorg.c and added NOPs with: XVECEXP (seq, 0, i) = emit_insn_after(tem, XVECEXP (seq, 0, i - 1)); or XVECEXP (seq, 0, i) = tem; But GCC will fail in both cases in final_scan_insn() or asm_noperands (). In both cases the CONST_INT (pattern for nop) is passed as a rtx pointer. so, how do I add NOP-instructions properly? Thanks, Boris
Re: [m32c] type precedence rules and pointer signs
On Jan 31, 2008 12:45 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> I'm debugging an EH failure on m32c-elf (-mcpu=m32c). The test case
> is this:
>
> extern int U();
>
> void *ra;
>
> main()
> {
> foo((ra + U()) - 1);
> }
>
> In the context of the bug, sizeof(void *) is 32 (well, PSImode = 24
> bit) and sizeof(int) == 16. U() returns zero in this example.
>
> So, the call is this:
>
> foo ((ra + 0) - 1)
>
> What gcc is doing is combining the +0 and -1 into a single value,
> resulting in:
>
> foo (ra - 1)
>
> However, it's storing the temporary sum in a 16 bit register and ZERO
> extending it to pointer size for the pointer math. Resulting
> in this:
>
> foo (ra + 0x)
>
> So, two questions:
>
> 1. What are the language rules controlling this expression, and do
>they have any say about signed vs unsigned wrt the int->pointer
>promotion? Pointers are "unsigned" on m32c, in that the unused
>bits in PSImode are assumed zero.
Ross answered this.
> 2. What part of gcc's target config would control how this expression
>is evaluated? If it had sign extended the value, it would have
>worked.
The problem you are running into is that sizeof(sizetype) != sizeof(void *).
In the middle-end the type used as offset (sizetype) doesn't have a
defined signedness (it's unsigned for C, signed for Ada for example), so
we rely on the fact that its size should match that of pointers (as then
we don't need to worry about sign or zero extension).
Yeah, we should have introduced a new type and not abused sizetype
here.
You can try fixing it in expansion of POINTER_PLUS_EXPR and force
sign-extension of the offset.
Richard.
[cygwin] FAIL: gcc.dg/vect/pr31041.c: gcc.dg/vect/pr31041.c:7: error: conflicting types for 'int32_t'
Hi. On cygwin with gcc trunk Fri Jan 25 12:38:35 UTC 2008 (revision 131824) I get the following failure (among a few others... many ICE) that might be easy to fix: Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/vect/pr31041.c -ftree-vectorize -fno-vect-cost-model -msse2 -O2 -fdump-tree-vect-details -fno-show-column -S -o pr31041.s(timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc/ /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/vect/pr31041.c -ftree-vectorize -fno-vect-cost-model -msse2 -O2 -fdump-tree-vect-details -fno-show-column -S -o pr31041.s /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/vect/pr31041.c:7: error: conflicting types for 'int32_t' /usr/include/stdint.h:20: error: previous declaration of 'int32_t' was here compiler exited with status 1 output is: /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/vect/pr31041.c:7: error: conflicting types for 'int32_t' /usr/include/stdint.h:20: error: previous declaration of 'int32_t' was here FAIL: gcc.dg/vect/pr31041.c (test for excess errors) Excess errors: /usr/local/src/trunk/gcc/gcc/testsuite/gcc.dg/vect/pr31041.c:7: error: conflicting types for 'int32_t' /usr/include/stdint.h:20: error: previous declaration of 'int32_t' was here -- Cheers, /ChJ
[cygwin, gnat] error: "system.ads" has restriction No_Implicit_Dynamic_Code
Hiya. On cygwin with gcc trunk Fri Jan 25 12:38:35 UTC 2008 (revision 131824), I get quite a few FAIL in the gnat testsuite due to errors like this: Executing on host: /usr/local/src/trunk/objdir/gcc/gnatmake -I/usr/local/src/trunk/objdir/gcc/ada/rts --GCC=/usr/local/src/trunk/objdir/gcc/xgcc --GNATBIND=/usr/local/src/trunk/objdir/gcc/gnatbind --GNATLINK=/usr/local/src/trunk/objdir/gcc/gnatlink -cargs -B/usr/local/src/trunk/objdir/gcc -largs --GCC=/usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc -margs -q -f /usr/local/src/trunk/gcc/gcc/testsuite/gnat.dg/abstract_with_anonymous_result.adb -I/usr/local/src/trunk/objdir/gcc/ada/rts -o ./abstract_with_anonymous_result.exe(timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/gnatmake -I/usr/local/src/trunk/objdir/gcc/ada/rts --GCC=/usr/local/src/trunk/objdir/gcc/xgcc --GNATBIND=/usr/local/src/trunk/objdir/gcc/gnatbind --GNATLINK=/usr/local/src/trunk/objdir/gcc/gnatlink -cargs -B/usr/local/src/trunk/objdir/gcc -largs --GCC=/usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc -margs -q -f /usr/local/src/trunk/gcc/gcc/testsuite/gnat.dg/abstract_with_anonymous_result.adb -I/usr/local/src/trunk/objdir/gcc/ada/rts -o ./abstract_with_anonymous_result.exe abstract_with_anonymous_result.adb:5:04: violation of restriction "No_Implicit_Dynamic_Code" at system.ads:44 abstract_with_anonymous_result.adb:6:12: violation of restriction "No_Implicit_Dynamic_Code" at system.ads:44 abstract_with_anonymous_result.adb:10:12: violation of restriction "No_Implicit_Dynamic_Code" at system.ads:44 gnatmake: "/usr/local/src/trunk/gcc/gcc/testsuite/gnat.dg/abstract_with_anonymous_result.adb" compilation error compiler exited with status 1 output is: abstract_with_anonymous_result.adb:5:04: violation of restriction "No_Implicit_Dynamic_Code" at system.ads:44 abstract_with_anonymous_result.adb:6:12: violation of restriction "No_Implicit_Dynamic_Code" at system.ads:44 abstract_with_anonymous_result.adb:10:12: violation of restriction "No_Implicit_Dynamic_Code" at system.ads:44 gnatmake: "/usr/local/src/trunk/gcc/gcc/testsuite/gnat.dg/abstract_with_anonymous_result.adb" compilation error FAIL: gnat.dg/abstract_with_anonymous_result.adb (test for excess errors) Excess errors: abstract_with_anonymous_result.adb:5:04: violation of restriction "No_Implicit_Dynamic_Code" at system.ads:44 abstract_with_anonymous_result.adb:6:12: violation of restriction "No_Implicit_Dynamic_Code" at system.ads:44 abstract_with_anonymous_result.adb:10:12: violation of restriction "No_Implicit_Dynamic_Code" at system.ads:44 WARNING: gnat.dg/abstract_with_anonymous_result.adb compilation failed to produce executable and Executing on host: /usr/local/src/trunk/objdir/gcc/gnatmake -I/usr/local/src/trunk/objdir/gcc/ada/rts --GCC=/usr/local/src/trunk/objdir/gcc/xgcc --GNATBIND=/usr/local/src/trunk/objdir/gcc/gnatbind --GNATLINK=/usr/local/src/trunk/objdir/gcc/gnatlink -cargs -B/usr/local/src/trunk/objdir/gcc -largs --GCC=/usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc -margs -q -f /usr/local/src/trunk/gcc/gcc/testsuite/gnat.dg/aggr2.adb -c -I/usr/local/src/trunk/objdir/gcc/ada/rts -S -o aggr2.s(timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/gnatmake -I/usr/local/src/trunk/objdir/gcc/ada/rts --GCC=/usr/local/src/trunk/objdir/gcc/xgcc --GNATBIND=/usr/local/src/trunk/objdir/gcc/gnatbind --GNATLINK=/usr/local/src/trunk/objdir/gcc/gnatlink -cargs -B/usr/local/src/trunk/objdir/gcc -largs --GCC=/usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc -margs -q -f /usr/local/src/trunk/gcc/gcc/testsuite/gnat.dg/aggr2.adb -c -I/usr/local/src/trunk/objdir/gcc/ada/rts -S -o aggr2.s aggr2.adb:4:04: violation of restriction "no_implicit_dynamic_code" at system.ads:44 gnatmake: "/usr/local/src/trunk/gcc/gcc/testsuite/gnat.dg/aggr2.adb" compilation error compiler exited with status 1 output is: aggr2.adb:4:04: violation of restriction "no_implicit_dynamic_code" at system.ads:44 gnatmake: "/usr/local/src/trunk/gcc/gcc/testsuite/gnat.dg/aggr2.adb" compilation error FAIL: gnat.dg/aggr2.adb (test for excess errors) Excess errors: aggr2.adb:4:04: violation of restriction "no_implicit_dynamic_code" at system.ads:44 and Executing on host: /usr/local/src/trunk/objdir/gcc/gnatmake -I/usr/local/src/trunk/objdir/gcc/ada/rts --GCC=/usr/local/src/trunk/objdir/gcc/xgcc --GNATBIND=/usr/local/src/trunk/objdir/gcc/gnatbind --GNATLINK=/usr/local/src/trunk/objdir/gcc/gnatlink -cargs -B/usr/local/src/trunk/objdir/gcc -largs --GCC=/usr/local/src/trunk/objdir/gcc/xgcc -B/usr/local/src/trunk/objdir/gcc -margs -q -f /usr/local/src/trunk/gcc/gcc/testsuite/gnat.dg/array3.adb -I/usr/local/src/trunk/objdir/gcc/ada/rts -o ./array3.exe (timeout = 300) spawn /usr/local/src/trunk/objdir/gcc/gnatmake -I/usr/local/src/trunk/objdir/gcc/ada/rts --GCC=/usr/local/src/trunk/objdir/gcc/xgcc --GNATBIND=/usr/local/src/trunk/objdir/gcc/gnatbind --GNATLINK=/usr/loc
Re: Inserting NOP instructions and branch delay slots
Boris Boesler <[EMAIL PROTECTED]> writes: > I have to insert NOP-instructions into the insn-stream in my back- > end. I do this with something ala emit_insn_after(gen_nop, xyz). This > works so far. > > GCC leaves control-flow operations as they are, if it there are no > instructions which can be used to fill the branch delay slots. My > first idea was to convert these control-flow cf to SEQUENCE(cf) and > hope the GCC will invoke DBR_OUTPUT_SEQEND(), but it does not? My > second idea was to add these NOP-instructions: SEQUENCE(cf, > NOP,...,NOP). I "reused" the code in function emit_delay_sequence() > in reorg.c and added NOPs with: > XVECEXP (seq, 0, i) = emit_insn_after(tem, XVECEXP (seq, 0, i - 1)); > or > XVECEXP (seq, 0, i) = tem; > But GCC will fail in both cases in final_scan_insn() or asm_noperands > (). In both cases the CONST_INT (pattern for nop) is passed as a rtx > pointer. > > so, how do I add NOP-instructions properly? I'm not quite sure what you're trying to do here. Do you need to insert nops in delay slots only, or do you need to insert nops at other places too (such as to work around processor errata)? If the former: you don't need to make delay-slot nops explicit in the rtl. Just make your branch output patterns add whatever nops are needed. See the MIPS port for an example. E.g. on MIPS, a plain "jr foo" JUMP_INSN is written as: jr foo nop (Specifically, MIPS uses a special '%/' asm punctuation character, so that: "jr\t%0%/" will print a nop if the rtl has no explicit delay slot.) If you need to insert nops outside delay slots, than you should do it after delayed-branch scheduling. Again, MIPS has examples of this; it calls dbr_schedule from within md_reorg. Not sure if that's any help though, sorry... Richard
Re: Contributing to cross-compiling
2008/1/31, Manuel López-Ibáñez <[EMAIL PROTECTED]>: > Nonetheless, if someone decided to go through the hassle of collecting > tutorials and hints for various cross-compiling configurations in the > wiki, I think many users will appreciate it. It is still considered by > many to be a "dark art"[*]. The crosstool project http://kegel.com/crosstool is a humungous shell script with configuration files that has collected a lot of the "community wisdom" over the years about the necessary runes to build cross-compilers for different scenarios and with different target-cpu/gcc/glibc/OS combinations. There is also a menu-driven spin-off project, crosstool-ng, which is less mature but embodies the same set of knowledge. M
Re: Proper way to make a one-off multi-file testcase?
> One issue here is that in some cases const and pure calls can get
> combined and eliminated even with attribute noinline (unless this
> changed recently). So in addition to attribute noinline, putting an
> asm volatile ("") in the function can help make it non-pure and
> non-const.
Yes, that did the trick.
FWIW, I am using a compiler based on gcc 4.2.1 .
We (ARC) will have to work with this version for a while longer because we
are participating in the Milepost research project ( http://www.milepost.eu/ )
and not all partners were happy with going to a GPLv3 GCC when we decided
on the base version.
Re: [m32c] type precedence rules and pointer signs
On Jan 31, 2008 8:40 PM, DJ Delorie <[EMAIL PROTECTED]> wrote: > > > The problem you are running into is that sizeof(sizetype) != > > sizeof(void *). In the middle-end the type used as offset > > (sizetype) doesn't have a defined signedness (it's unsigned for C, > > signed for Ada for example), so we rely on the fact that its size > > should match that of pointers (as then we don't need to worry about > > sign or zero extension). > > That kind of assumption just isn't going to work for m32c, because > there aren't enough pointer-sized operators to satisfy gcc, so pointer > math has to be done in a smaller mode. Doing it in a larger mode is > way too slow (all emulated math). > > So... now what? There are two parts of the problem. One is the tree representation of pointer offsets (it uses sizetype) and one is how this is expanded to RTL. The fix probably lies at expansion (at least for 4.3) - even though we might want to change the use of sizetype to some other type in 4.4. Can you represent all pointer offsets (well, those you actually support) within sizetype? If so you probably only need to adjust expansion of POINTER_PLUS_EXPR. Richard.
Re: [m32c] type precedence rules and pointer signs
> The problem you are running into is that sizeof(sizetype) != > sizeof(void *). In the middle-end the type used as offset > (sizetype) doesn't have a defined signedness (it's unsigned for C, > signed for Ada for example), so we rely on the fact that its size > should match that of pointers (as then we don't need to worry about > sign or zero extension). That kind of assumption just isn't going to work for m32c, because there aren't enough pointer-sized operators to satisfy gcc, so pointer math has to be done in a smaller mode. Doing it in a larger mode is way too slow (all emulated math). So... now what?
Re: [m32c] type precedence rules and pointer signs
> Can you represent all pointer offsets (well, those you actually > support) within sizetype? Yes. It's a limit, but we live with it. It would be nice if the offsets were extended according to their own sign, which gives us 1.5x the range of choosing a single signedness. > If so you probably only need to adjust expansion of > POINTER_PLUS_EXPR. Which file would that be in? It wasn't obvious from a simple grep. Or is that sprinkled all over the place?
Re: [m32c] type precedence rules and pointer signs
On Jan 31, 2008 12:00 PM, DJ Delorie <[EMAIL PROTECTED]> wrote: > Which file would that be in? It wasn't obvious from a simple grep. > Or is that sprinkled all over the place? The expansion is in expr.c with a comment of: case POINTER_PLUS_EXPR: /* Even though the sizetype mode and the pointer's mode can be different expand is able to handle this correctly and get the correct result out of the PLUS_EXPR code. */ It falls through to the normal PLUS_EXPR code. Thanks, Andrew Pinski
Re: [m32c] type precedence rules and pointer signs
On Jan 31, 2008 9:11 PM, DJ Delorie <[EMAIL PROTECTED]> wrote: > > > case POINTER_PLUS_EXPR: > > /* Even though the sizetype mode and the pointer's mode can be > > different > > expand is able to handle this correctly and get the correct result > > out > > of the PLUS_EXPR code. */ > > Me thinks that comment now needs some rethinking ;-) :) It's correct to always sign-extend the offset to the pointer mode width (or simply truncate it, if the offset width is larger than pointer mode width). Richard.
Re: [m32c] type precedence rules and pointer signs
> It's correct to always sign-extend the offset to the pointer mode > width (or simply truncate it, if the offset width is larger than > pointer mode width). I'd argue against that if you're dereferencing a large structure pointer. P->foo would always be an unsigned offset. Similarly for arrays, although one could argue either way with that. In the m32c case, though, the offset is a signed type, but an unsigned extension was used. The mismatch is the problem. Either way, there's going to be a compromise.
Re: [m32c] type precedence rules and pointer signs
> case POINTER_PLUS_EXPR: > /* Even though the sizetype mode and the pointer's mode can be different > expand is able to handle this correctly and get the correct result > out > of the PLUS_EXPR code. */ Me thinks that comment now needs some rethinking ;-)
Re: [m32c] type precedence rules and pointer signs
On Jan 31, 2008 9:26 PM, DJ Delorie <[EMAIL PROTECTED]> wrote: > > > It's correct to always sign-extend the offset to the pointer mode > > width (or simply truncate it, if the offset width is larger than > > pointer mode width). > > I'd argue against that if you're dereferencing a large structure > pointer. P->foo would always be an unsigned offset. Similarly for > arrays, although one could argue either way with that. You cannot tell the unsigned case apart from the signed case and structure dereferences are using COMPONENT_REF, not POINTER_PLUS_EXPR. The middle-end assumes that the offset part of POINTER_PLUS_EXPR is signed, so to extend it this way during expansion would be the natural thing to do. > In the m32c case, though, the offset is a signed type, but an unsigned > extension was used. The mismatch is the problem. Yes, but sizetype is unsigned (but sign-extended - which is appearantly not enforced at expansion here). > Either way, there's going to be a compromise. I don't think it's a compromise - it's just a bugfix ;) Richard.
Re: Help with compiling pdf manual
On Mon, 21 Jan 2008, Tomas Bily wrote:
> Line 1250 in invoke.texi looks like: @include
> @value{srcdir}/../libiberty/at-file.texi
>
> It seems that @value{srcdir} after @include is not expanded (though). I
> found in archives that this problem was found few years ago
> (http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00609.html) and problem
> was solved by checking if it is installed makeinfo >= 4.8. I am using
> 4.9. It seems that all other manual targets (html, info ...) work ok.
>
> Do you have any recomendations for me ?
>
> Greetings
>
> Tomas
>
> ps. I checked pdf version of manual on webpages
> (http://gcc.gnu.org/onlinedocs/gccint.pdf) and I looked at page where
> is @include ... included (page 25 bottom) and there is some mess.
I think this is a texinfo.tex bug and have sent a patch to the Texinfo
maintainers; if accepted we can import the new texinfo.tex to trunk and
4.2 branch.
The difference between failing to build for some people and mess in the
output for others is that some TeX installations include a file called
just ".tex" and others don't. If you have that file, it includes that
(and produces mess in the output), otherwise it gives the error you had.
--
Joseph S. Myers
[EMAIL PROTECTED]
