Re: [RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop
On 4/2/06, Roger Sayle <[EMAIL PROTECTED]> wrote: > > Following some of my recent middle-end clean-ups, I believe that > we're now at the point where incrementally the middle-end can > start ignoring the TREE_OVERFLOW bits on constant tree nodes. > As a step in this direction, the patch below removes the > TREE_CONSTANT_OVERFLOW checks from integer_zerop, integer_onep, > and friends in tree.c. This patch bootstraps and regression > tests on i686-pc-linux-gnu (including Ada) with no new failures. > > The major true user of TREE_CONSTANT_OVERFLOW is the C front-end, > which doesn't use any of these functions to determine whether it > should issue a diagnostic when an overflowed integer is used in > a context requiring a compile-time constant. > > Over the years, this overflow testing in the middle-end has caused > numerous bugs, the most recent being last week's PR26859. Removing > this test cleans up the semantics of integer constants a little. > In the unlikely event that any problems are discovered, by routines > relying on these functions testing checking for overflow, the trivial > fix is to rewrite the callers as: > > if (integer_zerop (t) > && ! TREE_CONSTANT_OVERFLOW (t)) > ... > > > There is now a stronger requirement on fold-const.c and friends that > it now be extra careful preserving TREE_CONSTANT_OVERFLOW for the > C front-end. Optimizations such as "0 * x" -> "0" where we > test for zero using integer_zerop, have been checked to make sure > that we return the original zero, which the overflow bits set as > appropriate. > > Once this patch is approved there's some follow-up clean-up that > can be done, removing the duplication in the many "local" functions > that test for zero but couldn't previously use integer_zerop due > to the historical overflow semantics. > > > Presumably everyone agrees that this evolution is a good thing. > The contention is whether everyone agrees that we're ready for > such a step. Is such a transition safe for stage 3 mainline, > and/or would front-ends prefer some time to double check that > this won't cause problems on conformance tests not part of GCC's > testsuite. > > Thoughts? That fixes my problem that I have with PR27018. Richard.
Problem regarding canonicalization
I have a combiner pattern that converts a sub-cmp pattern to a cmp insn,
something like this -
"if (a-1 < 0)"
is converted to
"if (a<1)"
Now consider the following test case -
f(long a){return (--a > 0);}
main(){if(f(0x8000L)==0)abort();exit(0);}
The compiler generates the following code for f()
cmp r0, 1 ;;canonicalized
mov r0,1
sub.le r0,r0,r0
This works fine under normal circumstances. However, in the testcase,
the least negative no. i.e. 0x8000 (hereafer referred to as MIN) is
passed. When 1 is subtracted from MIN, by --a, it becomes positive and
the conditions get reversed thus leading to failure during execution.
Similar problem seems to arise when MAX is passed to a function that
does "return (++a < 0).
How do I tackle this problem? Anything I may be missing?
Thanks in advance.
Ashwin
Re: Segment registers support for i386
> It would take a massive target-specific backend hack to make that happen, as > GCC > currently only supports flat address spaces. ;-) I don't understand why. gcc currently consider every data access on i386 to be %ds:offset or %ss:offset depending on the instruction. The purpose is only to add a way to explicitly indicate the section to use then is could be %gs:offset or %fs:offset. I'm new in gcc hacking therefore I still have to learn more about the internals but at first glance it doesn't sounds like a so big work. Could you explain me why do you think it would take a massive target-specific backend ? Thanks a lot. -- Rémy SaissyJabberID: [EMAIL PROTECTED] Web: http://remysaissy.free.fr "L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années, mais celui qui a le plus senti la vie." J.-J. Rousseau, Emile.
RE: Problem regarding canonicalization
On 04 April 2006 10:39, Ashwin wrote: > I have a combiner pattern that converts a sub-cmp pattern to a cmp insn, > something like this - > "if (a-1 < 0)" > is converted to > "if (a<1)" > > When 1 is subtracted from MIN, > Similar problem seems to arise when MAX is passed to a function that > does "return (++a < 0). > > How do I tackle this problem? Anything I may be missing? Integer under/overflow being undefined behaviour? I imagine the point of this testcase is to spot potential breakage introduced by just such optimisations? cheers, DaveK -- Can't think of a witty .sigline today
Re: Problem regarding canonicalization
Ashwin writes:
> I have a combiner pattern that converts a sub-cmp pattern to a cmp insn,
> something like this -
> "if (a-1 < 0)"
> is converted to
> "if (a<1)"
>
> Now consider the following test case -
>
>
> f(long a){return (--a > 0);}
> main(){if(f(0x8000L)==0)abort();exit(0);}
>
>
> The compiler generates the following code for f()
>cmp r0, 1 ;;canonicalized
>mov r0,1
>sub.le r0,r0,r0
>
> This works fine under normal circumstances. However, in the testcase,
> the least negative no. i.e. 0x8000 (hereafer referred to as MIN) is
> passed. When 1 is subtracted from MIN, by --a, it becomes positive and
> the conditions get reversed thus leading to failure during execution.
>
> Similar problem seems to arise when MAX is passed to a function that
> does "return (++a < 0).
>
> How do I tackle this problem? Anything I may be missing?
Yes. Signed integer overflow is undefined in C, so this is not a
well-defined C program. For example, this program may trap.
So, the semantics of the C language allow this optimization. See 6.5
Para 5.
For unsigned types C is much more specific, and you must not do any
optimizations that do not return the correct result modulo 2**N, where
N is the wordlength. See 6.2.5 Para 9.
Some other languges targeted by gcc, such as the Java langauge, are
much more strict about the behaviour of integer overflow.
Andrew.
Re: Segment registers support for i386
Rémy Saissy writes: > > It would take a massive target-specific backend hack to make that > > happen, as GCC > currently only supports flat address spaces. ;-) > > I don't understand why. > gcc currently consider every data access on i386 to be %ds:offset or > %ss:offset > depending on the instruction. No, that's not true. gcc doesn't know about %ds or %ss. > The purpose is only to add a way to explicitly indicate the section > to use then is could be %gs:offset or %fs:offset. > > I'm new in gcc hacking therefore I still have to learn more about the > internals but > at first glance it doesn't sounds like a so big work. You'd have to teach gcc about different address spaces. For example, gcc would have to know that %gs:foo couldn't be accessed via %ds. Andrew.
Re: Segment registers support for i386
On 4/4/06, Andrew Haley <[EMAIL PROTECTED]> wrote: > Rémy Saissy writes: > > > > It would take a massive target-specific backend hack to make that > > > happen, as GCC > currently only supports flat address spaces. ;-) > > > > I don't understand why. > > gcc currently consider every data access on i386 to be %ds:offset or > %ss:offset > > depending on the instruction. > > No, that's not true. gcc doesn't know about %ds or %ss. oh sorry. that's what I though but It seems I explained it with a bad english ;) > > > The purpose is only to add a way to explicitly indicate the section > > to use then is could be %gs:offset or %fs:offset. > > > > I'm new in gcc hacking therefore I still have to learn more about the > > internals but > > at first glance it doesn't sounds like a so big work. > > You'd have to teach gcc about different address spaces. For example, > gcc would have to know that %gs:foo couldn't be accessed via %ds. > Ok. thanks you too for your anwers, I'll try to do something good now ;) Have a great day. -- Rémy SaissyJabberID: [EMAIL PROTECTED] Web: http://remysaissy.free.fr "L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années, mais celui qui a le plus senti la vie." J.-J. Rousseau, Emile.
Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller
It seems that there is already a PIC port for gcc.. in the form of Microchips own MPLAB C30 compiler.. I didn't realise this (and google certainly didn't tell me) until I had started on the PIC14 port for gcc, and went to the Microchip website for some info, and searched on "C compiler" and then "gcc" out of curiosity... lo and behold, the source code for their port.. (based on gcc 3.3, it seems). It supports "Microchip 16-bit devices: PIC24, dsPIC30F and dsPIC33F" Microchip sells MPLAB C30 as a commercial product. On the "Buy It now" page, they have a link to the source code though, so I grabbed a copy... :) (Part Number: SW006012 - MPLAB C30 C Compiler for dsPIC30/33, PIC24: (GBP) £ 513 ) Colm
Re: gcc3.4.5: bug with inline on ppc405?
On Mon, Apr 03, 2006 at 10:31:19AM -0400, Martin Hicks wrote: > > Hi, > > I've run into a piece of code on ppc405 that does the wrong thing when a > function is automatically inlined. I don't really do ppc asm so I > haven't been able to isolate what exactly the problem is, but the code > blatantly takes the wrong branch. > > The toolchain I'm using is a cross compiler from x86 to ppc. The target > is a 405gp. I built this gcc-3.4.5/binutils-2.15/glibc-2.3.6 compiler > using crosstools-0.42 > I built a gcc-4.0.3/binutils-2.16/glibc-2.3.6 cross toolchain yesterday and this fixes the problem. I can't really use gcc-4, due to the vintage of the kernel that I'm using. Does anyone have any ideas what this bug is? Is there an open bug? mh -- Martin Hicks || [EMAIL PROTECTED] || PGP/GnuPG: 0x4C7F2BEE signature.asc Description: Digital signature
i686-pc-linux-gnu bootstrap failure in unified tree on gdb/p-valprint.c
configured with: ../srcw/configure --with-arch=i686 --enable-languages=c,c++,java,objc failure: /mnt/scratch/nightly/2006-04-03/i686/./gcc/xgcc -B/mnt/scratch/nightly/2006-04-03/i686/./gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include -L/mnt/scratch/nightly/2006-04-03/i686/./ld -c -O2 -g -O2 -I. -I../../srcw/gdb -I../../srcw/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../srcw/gdb/../include/opcode -I../../srcw/gdb/../readline/.. -I../bfd -I../../srcw/gdb/../bfd -I../../srcw/gdb/../include -I../intl -I../../srcw/gdb/../intl -DMI_OUT=1 -DTUI=1 -Wimplicit -Wreturn-type -Wcomment -Wtrigraphs -Wformat -Wparentheses -Wpointer-arith -Wformat-nonliteral -Wunused-label -Wunused-function -Wno-pointer-sign -Wuninitialized -Werror ../../srcw/gdb/p-valprint.c cc1: warnings being treated as errors ../../srcw/gdb/p-valprint.c: In function ‘pascal_object_print_value_fields’: ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.alloc_failed’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.maybe_empty_object’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.use_extra_arg’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.extra_arg’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.freefun’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.chunkfun’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.alignment_mask’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.temp’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.chunk_limit’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.next_free’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.object_base’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.chunk’ may be used uninitialized in this function ../../srcw/gdb/p-valprint.c:756: warning: ‘tmp_obstack.chunk_size’ may be used uninitialized in this function make[2]: *** [p-valprint.o] Error 1 make[2]: Leaving directory `/mnt/scratch/nightly/2006-04-03/i686/gdb' make[1]: *** [all-gdb] Error 2 make[1]: Leaving directory `/mnt/scratch/nightly/2006-04-03/i686' make: *** [bootstrap] Error 2
Re: GCC SC request about ecj
> Ranjit Mathew writes: Ranjit> Did the SC get to deliberate on this issue? Was this Ranjit> message: Ranjit> http://gcc.gnu.org/ml/gcc/2006-03/msg00558.html Ranjit> on inclusion of source code from other projects in GCC a Ranjit> direct result of these discussions or a mere coincidence? Yes, the GCC SC has discussed it. The discussion was sidetracked by a number of issues, including the one referenced. We are waiting for RMS to comment. David
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES
Hi, I've sent this request for assignment last week to [EMAIL PROTECTED] Will I receive (only) a snail mail answer? Did I submit the right version of the form? Thanks for any help, Nic. -- REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES [What is the name of the program or package you're contributing to?] gcc [Did you copy any files or text written by someone else in these changes? Even if that material is free software, we need to know about it.] No. [Do you have an employer who might have a basis to claim to own your changes? Do you attend a school which might make such a claim?] No. [For the copyright registration, what country are you a citizen of?] Romania. [What year were you born?] 1968. [Please write your email address here.] [EMAIL PROTECTED] [Please write your postal address here.] 4 rue Villebois Mareuil 78110 Le Vesinet FRANCE [Which files have you changed so far, and which new files have you written so far?] 1. Files changed: common.opt diagnostic.h dlcheck.c flags.h Makefile.in opts.c pretty-print.c pretty-print.h timevar.def toplev.c tree.c tree.h tree-optimize.c tree-pass.h tree-pretty-print.c 2. New files: tree-pattern.h (133 lines) tree-check.c (409 lines) tree-match.c (478 lines)
v850, dwarf2, too many fp-sp compensations?
The v850 is a dwarf-debug target, but not a dwarf-unwind target. In
dwarf2out.c we first calculate the "fp to fb offset" in
compute_frame_pointer_to_fb_displacement. The frame pointer is not
needed, so note that we include the fp-sp elimination offset in
frame_pointer_fb_offset.
\/
/* Compute a displacement from the "steady-state frame pointer" to the
frame base (often the same as the CFA), and store it in
frame_pointer_fb_offset. OFFSET is added to the displacement
before the latter is negated. */
static void
compute_frame_pointer_to_fb_displacement (HOST_WIDE_INT offset)
{
rtx reg, elim;
#ifdef FRAME_POINTER_CFA_OFFSET
reg = frame_pointer_rtx;
offset += FRAME_POINTER_CFA_OFFSET (current_function_decl);
#else
reg = arg_pointer_rtx;
offset += ARG_POINTER_CFA_OFFSET (current_function_decl);
#endif
elim = eliminate_regs (reg, VOIDmode, NULL_RTX);
if (GET_CODE (elim) == PLUS)
{
offset += INTVAL (XEXP (elim, 1));
elim = XEXP (elim, 0);
}
gcc_assert (elim == (frame_pointer_needed ? hard_frame_pointer_rtx
: stack_pointer_rtx));
frame_pointer_fb_offset = -offset;
}
/\
Later, when we calculate function parameter locations, we end up in
based_loc_descr(). We call eliminate_regs again, adjust for the
elimination offset, then adjust for frame_pointer_fb_offset, which
*also* includes the elimination offset:
\/
static dw_loc_descr_ref
based_loc_descr (rtx reg, HOST_WIDE_INT offset)
{
unsigned int regno;
/* We only use "frame base" when we're sure we're talking about the
post-prologue local stack frame. We do this by *not* running
register elimination until this point, and recognizing the special
argument pointer and soft frame pointer rtx's. */
if (reg == arg_pointer_rtx || reg == frame_pointer_rtx)
{
rtx elim = eliminate_regs (reg, VOIDmode, NULL_RTX);
if (elim != reg)
{
if (GET_CODE (elim) == PLUS)
{
offset += INTVAL (XEXP (elim, 1));
elim = XEXP (elim, 0);
}
gcc_assert (elim == (frame_pointer_needed ? hard_frame_pointer_rtx
: stack_pointer_rtx));
offset += frame_pointer_fb_offset;
return new_loc_descr (DW_OP_fbreg, offset, 0);
}
}
/\
The net result is that the dwarf2 debug information is off by the
fp-sp offset. My question is: which of these adjustments isn't
supposed to happen in this case?
Thanks,
DJ
preview of the tree-check pass (Re: gcc project)
OK, I have put a preview of the tree-check pass (performing lightweight user-defined checks) on: http://mygcc.free.fr. Any comments are welcome. Nic. On Tue, 2006-03-28 at 17:23, Diego Novillo wrote: > On 03/27/06 16:35, Nic Volanschi wrote: > > > The checks are specified using a new option --tree-check, and are > > powerful enough to express user-defined memory leaks, null pointer > > dereferences, unreleased locks, etc., but also more basic checks such > > as using an unsafe construct. [...] > I'd be very interested in taking a look at what you've done. Perhaps > the best approach for you now is to get this code into a branch. We > already are in a "no new features" stage for 4.2. >
floating point fwaits for i386
Dear Gnu gcc person, We have written our own FP exception handler for our use (because we want 1e155*1e155 to return 1.797...e308 (maxpos), and not a NaN!, and so on.) For this to work in our gcc-compiled code, we need gcc to generate fwaits where needed (after all non-interrupting FP instructions) so that we can catch the exception at the right time and handle it appropriately. For the old gcc 2.91 - 2.96 compilers on i386 architecture, this worked! For the gcc 3.2 compiler we are trying to use, this no longer works. (If we put an asm fwait in our test code, good behavior is restored - but of course we don't want to sprinkle hundreds or thousands of fwaits everywhere.) There seems to be no compiler switch to ask for these fwaits we have tried -ftrapv and many other options. Could you possibly add a switch -mfwait to the i386 batch of switches to get us back the capability we need. Thanks. -- == | Spoken: Gary D. Knott Email: [EMAIL PROTECTED] | | Phone: (301) 962-3711 MIME mail welcome| | | | web: www.civilized.com (Please look at our HomePage!) | | USPS: Civilized Software Inc., 12109 Heritage Park Circle, | | Silver Spring, Maryland 20906, USA| ==
Re: floating point fwaits for i386
Gary Knott wrote: Dear Gnu gcc person, We have written our own FP exception handler for our use (because we want 1e155*1e155 to return 1.797...e308 (maxpos), and not a NaN!, and so on.) I assume you mean plus infinity? For this to work in our gcc-compiled code, we need gcc to generate fwaits where needed (after all non-interrupting FP instructions) so that we can catch the exception at the right time and handle it appropriately. For the old gcc 2.91 - 2.96 compilers on i386 architecture, this worked! For the gcc 3.2 compiler we are trying to use, this no longer works. (If we put an asm fwait in our test code, good behavior is restored - but of course we don't want to sprinkle hundreds or thousands of fwaits everywhere.) There seems to be no compiler switch to ask for these fwaits we have tried -ftrapv and many other options. Not too surprising, the effect on performance should be drastically horrible, so it is not something you want to encourage. Could you possibly add a switch -mfwait to the i386 batch of switches to get us back the capability we need. Thanks.
