RE: suggest assert wide_int larger than hashval_t (32bit hwint?)
Hm, it seems on some 32bit systems, where there is no -m64, wideint can be a
mere 32bits.
In which case the code should probably say:
hwi = ((hwi >> (shift - 1)) >> 1);
This was targeting OpenBSD/x86.
Maybe I should just stick need_64bit_hwint = yes on config.gcc for that and
move along?
Assume there is always long long or __int64?
Coverage of this case is pretty rare now from my skimming.
- Jay
> From: jay.kr...@cornell.edu
> To: gcc@gcc.gnu.org
> Subject: suggest assert wide_int larger than hashval_t
> Date: Mon, 19 Jul 2010 06:44:33 +
>
>
> I get this in 4.3.5:
>
> ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
> ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
>
> ./include/hashtab.h:typedef unsigned int hashval_t;
>
> unsigned HOST_WIDE_INT hwi;
> hashval_t h, *hp;
> ...
> const int shift = sizeof (hashval_t) * CHAR_BIT;
> const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
> int i;
>
> h ^= (hashval_t) hwi;
> for (i = 1; i < n; ++i)
> {
> hwi >>= shift; here
>
>
> It looks about the same in 4.5.0 except without const:
>
>
> int shift = (sizeof (hashval_t) * CHAR_BIT);
>
>
> Something is amiss here locally, for the types to be the same size.
>
>
> But maybe add gcc_assert(sizeof(hashval_t) < sizeof(HOST_WIDE_INT),
> outside the loop? It should be optimized away anyway.
>
>
> Maybe I'd get -Werror but I use -disable-bootstrap.
> Native compiler is gcc, but old.
>
>
> Thanks,
> - Jay
>
>
Re: suggest assert wide_int larger than hashval_t
Jay K writes:
> I get this in 4.3.5:
>
> ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
> ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
>
> ./include/hashtab.h:typedef unsigned int hashval_t;
>
> unsigned HOST_WIDE_INT hwi;
> hashval_t h, *hp;
> ...
> const int shift = sizeof (hashval_t) * CHAR_BIT;
> const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
> int i;
>
> h ^= (hashval_t) hwi;
> for (i = 1; i < n; ++i)
> {
> hwi >>= shift; here
It's not an actual problem, because the code is never executed in the
case where right shift count >= width of type. Note that the loop
starts at 1. If this is breaking bootstrap that it needs to be
addressed one way or another, otherwise it's not too serious.
Ian
question about float insns like ceil/floor on mips machine
Hi: I found although there are standard pattern names such as "ceilm2/floorm2", there is no insn pattern in mips.md for such float insns on mips target. further more, there is no ceil/floor rtl code in rtl.def either. based on these facts, I assuming those float insns are not supported by gcc, but don't know why, seems not difficult to add such insns. Did I miss anything important? please help, thanks. -- Best Regards.
RE: suggest assert wide_int larger than hashval_t
It's "just" a warning, no "real" affects seen.
I patched my copy to say
hwi = ((hwi >> (shift - 1)) >> 1);
Thanks,
- Jay
> From: i...@google.com
> To: jay.kr...@cornell.edu
> CC: gcc@gcc.gnu.org
> Subject: Re: suggest assert wide_int larger than hashval_t
> Date: Mon, 19 Jul 2010 00:36:06 -0700
>
> Jay K writes:
>
> > I get this in 4.3.5:
> >
> > ../../gcc/gcc/varasm.c: In function `const_rtx_hash_1':
> > ../../gcc/gcc/varasm.c:3387: warning: right shift count >= width of type
> >
> > ./include/hashtab.h:typedef unsigned int hashval_t;
> >
> > unsigned HOST_WIDE_INT hwi;
> > hashval_t h, *hp;
> > ...
> > const int shift = sizeof (hashval_t) * CHAR_BIT;
> > const int n = sizeof (HOST_WIDE_INT) / sizeof (hashval_t);
> > int i;
> >
> > h ^= (hashval_t) hwi;
> > for (i = 1; i < n; ++i)
> > {
> > hwi >>= shift; here
>
> It's not an actual problem, because the code is never executed in the
> case where right shift count >= width of type. Note that the loop
> starts at 1. If this is breaking bootstrap that it needs to be
> addressed one way or another, otherwise it's not too serious.
>
> Ian
Re: question about float insns like ceil/floor on mips machine
"Amker.Cheng" writes: > I found although there are standard pattern names such as "ceilm2/floorm2", > there is no insn pattern in mips.md for such float insns on mips target. > further more, there is no ceil/floor rtl code in rtl.def either. > > based on these facts, I assuming those float insns are not supported by gcc, > but don't know why, seems not difficult to add such insns. You're right that gcc does not currently have a way to represent those instructions directly in RTL. In current gcc it would have to be done using an unspec. E.g., see ceildf2 and ceildf2_fpr in rs6000.md. You're also right that it would not be difficult to add direct RTL support. I'm not sure how useful that would be, since I don't see a lot of additional optimization opportunity. An unspec will handle scheduling correctly, the only benefit I see of direct RTL exposure would be that you could do optimizations like floor(ceil(x)) => ceil(x), but that seems unlikely to occur in real code. Ian
RE: SH optimized software floating point routines
Hi. Thank you for the modified patch. I have applied the patch to gcc-4.5 sources and checking the regression for SH[1234]. I will run some more tests on the modified (patched) toolchain. I will share the test results after the regression and other tests are complete. Regards, Naveen
Re: question about float insns like ceil/floor on mips machine
On Mon, Jul 19, 2010 at 11:12 AM, Ian Lance Taylor wrote: > "Amker.Cheng" writes: > >> I found although there are standard pattern names such as "ceilm2/floorm2", >> there is no insn pattern in mips.md for such float insns on mips target. >> further more, there is no ceil/floor rtl code in rtl.def either. >> >> based on these facts, I assuming those float insns are not supported by gcc, >> but don't know why, seems not difficult to add such insns. > > You're right that gcc does not currently have a way to represent those > instructions directly in RTL. In current gcc it would have to be done > using an unspec. E.g., see ceildf2 and ceildf2_fpr in rs6000.md. > > You're also right that it would not be difficult to add direct RTL > support. I'm not sure how useful that would be, since I don't see a lot > of additional optimization opportunity. An unspec will handle > scheduling correctly, the only benefit I see of direct RTL exposure > would be that you could do optimizations like floor(ceil(x)) => ceil(x), > but that seems unlikely to occur in real code. And we'd be doing that at the tree level anyway. Richard. > Ian >
gcc command line exceeds 8191 when building in XP
Hi, I'm building a project using GNU gcc, but the command line used to build each source file sometimes exceeds 8191 characters, which is the maximum supported command line length under Win XP.Even worst under Win 2000, where the maximum command line length is limited to 2047 characters. Can the GNU gcc read the build options from a file instead ?I have searched, but cannot find an option in the documentation. Thanks in advance, ICB -- View this message in context: http://old.nabble.com/gcc-command-line-exceeds-8191-when-building-in-XP-tp29205136p29205136.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: gcc command line exceeds 8191 when building in XP
On 7/19/2010 4:13 PM, IceColdBeer wrote: Hi, I'm building a project using GNU gcc, but the command line used to build each source file sometimes exceeds 8191 characters, which is the maximum supported command line length under Win XP.Even worst under Win 2000, where the maximum command line length is limited to 2047 characters. Can the GNU gcc read the build options from a file instead ?I have searched, but cannot find an option in the documentation. Thanks in advance, ICB redirecting to gcc-help. The gcc builds for Windows themselves use a scheme for splitting the link into multiple steps in order to deal with command line length limits. I would suggest adapting that. Can't study it myself now while travelling. -- Tim Prince
Re: gcc command line exceeds 8191 when building in XP
Tim Prince wrote: On 7/19/2010 4:13 PM, IceColdBeer wrote: Hi, I'm building a project using GNU gcc, but the command line used to build each source file sometimes exceeds 8191 characters, which is the maximum supported command line length under Win XP.Even worst under Win 2000, where the maximum command line length is limited to 2047 characters. Can the GNU gcc read the build options from a file instead ?I have searched, but cannot find an option in the documentation. Thanks in advance, ICB redirecting to gcc-help. The gcc builds for Windows themselves use a scheme for splitting the link into multiple steps in order to deal with command line length limits. I would suggest adapting that. Can't study it myself now while travelling. @file says the manpage. "Read command-line options from file."
Re: [Bulk] Re: [Bulk] Re: Edit-and-continue
Rick, You are seeking perfection while I am suggesting a technique that doesn't capture all cases but is useful: 1) change only the body of a function 2) compile the new function into a shared library which the debugger dlopen's into the target process. 3) replace the entry-point code of the old function with a branch to the new version. On 7/18/2010 12:52 PM, Rick C. Hodgin wrote: Terrence, Procedure entry points, global and local variable locations in memory, structure definitions and offsets, etc. These would all have to be updated as changes are made, and that means each reference used in the executable would need to be updated, and that could mean several source files are recompiled with a single change which affects it. And if there are shared resources loaded, each of those would have to be updated as well, that is if we wanted to go "whole hog" like that. Otherwise, we could limit the changes to only the currently-executing program. The idea of having function entry points across the board for all executed code would be required, allowing those links to be updated dynamically at run-time. We could even use a memory-based lookup table that's updated by gdb to the new entry points for the executable code. It would be slower for execution, but for development the time savings would be there because changes could be made on the fly, recompiled, memory variables changed as needed, and then continue execution without restarting the entire app. The ability would also have to be created to allow local variable re-mapping across these updates, so that if the stack changed, the data on the stack is migrated from its old locations to the new ones. This would be a table built by gcc that's passed to gdb for each function, where gdb updates the stack in that way. If parent functions on the call stack were updated, they would have to be altered on the stack as well. This could be accommodated by automatically including a specified amount of "extra space" in local variable space per function entry point, something like 32 bytes (eight 4-byte variables) by default, with a compiler switch to increase that block size. This extra space would allow for a certain number of new variables before a full recompile is required again. We could also have #pragma-like statements for individual functions where we know some heavy changes will be used, to give them an extra 512 bytes, or whatever's specified. - Rick C. Hodgin On Sun, 2010-07-18 at 12:36 -0700, Terrence Miller wrote: If you are willing to restrict edit-and-continue to whole procedures then minimal changes to the compiled code for procedure entry points is all that is required (well that and dlopen). Terrence MIller On 7/18/2010 12:14 PM, Dave Korn wrote: On 18/07/2010 16:28, Robert Dewar wrote: Rick Hodgin wrote: Ian, The idea is to create a program database of the compiled program on a full compile. Then when asked to re-compile with the edit-and-continue switch, it only looks for changed code and compiles those few lines. Everything else it needs to carry out compilation is there from previous full-compile as was originally parsed, or from subsequent edit-and-continue compiles which updated the database. Unlikely to be feasible in my view without slowing down compilation substantially. I think you're probably assuming too much. Tom T. is working on an incremental compiler, isn't he? I expect that that and LTO between them would / could give us all the tools we needed to make an EAC-friendly compiler. But yes, OP, it's a long-term project. cheers, DaveK
Re: Edit-and-continue
On Sun, Jul 18, 2010 at 14:37, Ian Lance Taylor wrote: > This idea is related to Tom Tromey's incremental compiler work > (http://gcc.gnu.org/wiki/IncrementalCompiler) and to Per Bothner's > compiler server work > (http://per.bothner.com/papers/GccSummit03-slides/index.html). Neither > project is currently active. I believe that Diego Novillo is currently > doing some work along these lines but I don't know what the status is. We are finishing up a prototype implementation for per-file pre-tokenization. If this works out, we will see about adding parsing results to the cache. Our goal would be to finish Tom's incremental compiler. But we are still very much in preliminary stages of the work. Diego.
Re: Edit-and-continue
> "Dave" == Dave Korn writes: Dave> I think you're probably assuming too much. Tom T. is working on an Dave> incremental compiler, isn't he? I was, but I was asked to work on gdb a couple of years ago, so that work is suspended. Dave> But yes, OP, it's a long-term project. Apple implemented fix-and-continue in their toolchain. They spoke about it a little bit on the gdb list, it is in the archives. My take-away was that the feature is a lot of work for not much benefit, but YMMV, and of course we'd be happy to review any gdb patches in this direction :-) Tom
Re: Edit-and-continue
On Jul 19, 2010, at 1:57 PM, Tom Tromey wrote: > Dave> But yes, OP, it's a long-term project. > > Apple implemented fix-and-continue in their toolchain. They spoke about > it a little bit on the gdb list, it is in the archives. My take-away > was that the feature is a lot of work for not much benefit, but YMMV, > and of course we'd be happy to review any gdb patches in this direction > :-) The use case for fix-and-continue is for long lived apps. This has little to do with actual build times, it is useful when restarting the app and getting it back into the state to repro the problem takes a long time. It is a useful feature and Apple did implement it in their toolchain, but it's worth noting that they've ripped it out since then. Their specific implementation was too fragile to work consistently. -Chris
