Gpc April 2010

gpc@gnu.de

8 participants
5 discussions

Inefficiency of `mod'
by Emil Jerabek 26 Oct '10

26 Oct '10

Hi, during some debugging I noticed that GPC generates very hairy code for the `mod' operator with signed arguments. A closer look revealed that the code contains a lot of branching on conditions which can be determined on compile time, and most surprisingly, the value of X mod Y is recomputed _twice_, if X is negative. (I've attached a commented assembler dump.) This may be partially a back-end problem (CSE?), but I feel there's something wrong in the relevant code in gpc-common.c (build_pascal_binary_op) as well. `exp1 mod exp2' gets translated into something like exp2 <= 0 ? error : exp1 >= 0 ? exp1 mod exp2 : ((-exp1) mod exp2) == 0 ? 0 : exp2 - (-exp1) mod exp2 This arranges that both arguments supplied to the "internal mod" are non-negative, but this information is not passed on -- the arguments are still declared as signed types, which apparently makes the back-end to produce the mess it does. I've done a little test: the following replacement for `mod', which differs from the built-in one essentially just by the type-casts to `Cardinal', inline operator xmod (X, Y: Integer) = Z: Integer; begin if Y <= 0 then RuntimeError (714); if X >= 0 then Z := Cardinal (X) mod Y else begin Z := Cardinal (-X) mod Y; if Z <> 0 then Z := Y - Z end end; indeed generates a better code, it measures about 15% faster for positive X and more than twice faster for negative X. YMMV. If this is possible in user code, it should work in the compiler internals as well :) The result type of the whole `mod' expression looks dubious too. IIUIC, `exp1 mod exp2' inherits the type of exp1. Now, the result of `mod' is guaranteed to be nonnegative and to fit in the type of exp2 (or more precisely, it is in 0 .. High (type of (exp2)) - 1), whereas it needn't have anything to do with the type of exp1: consider var X, Z: Integer; Y: LongInt; begin X := -8; Y := High (LongInt); Z := X mod Y { -> overflow } end Or am I missing something? Emil (BTW, where is fjf434c.pas?)

10 16

GPC debugging with Snow Leopard/Xcode 3.2
by Francesco Panasiti 29 Apr '10

29 Apr '10

I've moved a large GPC project from Mac OSX 10.4 to Snow Leopard (Xcode 3.2, Intel CPU). Compilation (GNU Pascal 3.4.6u4) is ok, but I can't start debugging from Xcode as I get the following error: ""Exception starting task (/Developer/usr/bin/gdb) ; name: NSInvalidArgumentException, reason: working directory doesn't exist"" With evidence, gdb is looking for the executable in the wrong directory, but I don't know how to workaround that. Thanks in advance for any help. ------------------------------------------------------------- Francesco Panasiti -------------------------------------------------------------

2 2

Fwd: [Fwd: GCC 4.5.0 Released]
by Rugxulo 21 Apr '10

21 Apr '10

Oops, replied to private e-mail instead! ---------- Forwarded message ---------- From: Rugxulo <rugxulo(a)gmail.com> Date: Tue, 20 Apr 2010 19:13:05 -0500 Subject: Re: [Fwd: GCC 4.5.0 Released] To: Adriaan van Os <gpc(a)microbizz.nl> Hi, just a few warnings from me. ;-) On 4/19/10, Adriaan van Os <gpc(a)microbizz.nl> wrote: > > The Free Software Foundation and the GNU Compiler Collection (GCC) > development team have released GCC 4.5.0. Clang is also self-hosting now, and ClangBSD can bootstrap (currently in testing but seems to basically work, from what I hear). > The developers have measured performance improvements of 5% to 10% > on high-performance computing benchmarks. (Of course, results vary > depending on choice of CPU, benchmark, and optimization options.) In my (horribly lame) experience, I saw some bad regressions with 4.4.2 vs. earlier GCCs. Granted, it was just one really weird case, but still, it makes me think even moreso that GCC is only 686-tuned these days. (I was trying to benchmark something on my old old 586.) It worries me a bit since I just assumed 4.x was always way better. (Note that I never bothered to isolate the problem just yet, it wasn't crucial or anything, just really odd. And it was a C program, not Pascal.) > GCC 4.5.0 is now capable of "link-time optimization". Only using an ELF container (although non-ELF targets can somehow possibly use it too, allegedly). Hopefully not as exclusive as Gold linker (x86/x86-64 ELF only). I do really feel like all the world's a Linux these days. :-/ > GCC also generates better debug information for optimized code, > including information about the value of variables that have been optimized > away. In other words, you need GDB 7+ by default (else have to choose an older Dwarf debug format via --dwarf-2 or whatever).

1 0

[Fwd: GCC 4.5.0 Released]
by Adriaan van Os 19 Apr '10

19 Apr '10

-------- Original Message -------- Subject: GCC 4.5.0 Released Date: Sun, 18 Apr 2010 16:01:49 -0700 (PDT) From: mitchell(a)codesourcery.com (Mark Mitchell) Reply-To: mark(a)codesourcery.com To: gcc-announce(a)gcc.gnu.org CC: gcc(a)gcc.gnu.org The Free Software Foundation and the GNU Compiler Collection (GCC) development team have released GCC 4.5.0. This release is a major upgrade to the compilers, with a particular focus on the performance of the generated code. The developers have measured performance improvements of 5% to 10% on high-performance computing benchmarks. (Of course, results vary depending on choice of CPU, benchmark, and optimization options.) GCC 4.5.0 is now capable of "link-time optimization". Traditionally, most C and C++ compilers (including GCC) have only been able to optimize within a single source file or "module". GCC was therefore unable to take advantage of optimization opportunities that required knowledge about multiple modules. This limitation has been removed in GCC 4.5.0. This optimization can provide significant increases in performance and equally significant reductions in code size. In addition, GCC 4.5.0 has improved loop optimization infrastructure. This infrastructure, based on an advanced "polyhedral" model for optimization, allows GCC to perform more advanced loop optimizations. In the future, this infrastructure will be tuned and used more heavily. GCC 4.5.0 also features improvements for a wide variety of specific architectures, including support for recent CPUs using the ARM, AVR, ColdFire, MIPS, Power, SuperH, and x86 architectures. GCC also generates better debug information for optimized code, including information about the value of variables that have been optimized away. And, of course, a wide variety of defects in all parts of the compiler (ranging from language conformance to code-generation) have been corrected. Refer to gcc.gnu.org: http://gcc.gnu.org/gcc-4.5/changes.html for more information about this release. GCC 4.5.1, with corrections for any critical defects reported in GCC 4.5.0, is expected in July, 2010. As always, a vast number of people contributed to this GCC release -- far too many to thank individually! -- Mark Mitchell CodeSourcery mark(a)codesourcery.com (650) 331-3385 x713

2 1

Disposing generic pointers
by John L. Ries 15 Apr '10

15 Apr '10

The other day, I compiled a unit I wrote several years ago under FPC and got the following warning: queues.p(101,37) Warning: use of NEW or DISPOSE for untyped pointers is meaningless The same unit compiles under GPC (20070904) without warnings. My question is: does GPC properly deallocate memory in such a case, or is the DISPOSE request ignored? The offending procedure is: procedure killq(var Queue : QType ); var Item : pointer; begin while(not EmptyQ(Queue)) do begin Dequeue(Queue,Item); if Item<>nil then dispose(Item); end; end; { killq } --------------------------| John L. Ries | Salford Systems | Phone: (619)543-8880 x107 | or (435)867-8885 | --------------------------|

5 14

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc April 2010