Mike Stump wrote:
In defaults.h, they do:
/* This is how to output an element of a case-vector that is absolute.
Some targets don't use this, but we have to define it anyway. */
#ifndef ASM_OUTPUT_ADDR_VEC_ELT
#define ASM_OUTPUT_ADDR_VEC_ELT(FILE, VALUE) \
This was added before gcc-2.3.3.
On Sat, 2005-07-02 at 11:40 +1000, Russell Shaw wrote:
> Stephen Torri wrote:
> > I am interested in reading the actual grammar files used for parsing C
> > and C++ programming languages inside gcc. Where are these files located?
> >
> > Stephen
>
> gcc-3.4.3/gcc/c-parse.in
> gcc-3.4.3/gcc/c-pars
Martin Koegler wrote:
I continued to work on the support for named address spaces in GCC.
This does look like a good start.
An possible issue is the effect on gcc memory usage and compile time. I
see you increased the size of MEM rtl which will increase memory usage.
Also, there seem to be
Stephen Torri wrote:
I am interested in reading the actual grammar files used for parsing C
and C++ programming languages inside gcc. Where are these files located?
Stephen
gcc-3.4.3/gcc/c-parse.in
gcc-3.4.3/gcc/c-parse.y
> Trying to fake two kinds of pointers when we only have one doesn't seem
> wise to me.
>
> A possible solution is to use function descriptors.
Both m32c (my local copy at least) and xstormy use 16 bit thunks to
reference the address of a function outside the first 64k of address
space.
In thi
The finite automaton used in the pipeline hazard recognizer uses a cycle
advancing arc in every state to represent a clock pulse. Bala(1) uses a
different technique: All states were a instruction issue is not possible are
marked as "cycle advancing" and the pipeline state is update to reflect a
DJ Delorie wrote:
For some chips, like xstormy16 and m16c, function pointers are wider
than other pointers.
Trying to fake two kinds of pointers when we only have one doesn't seem
wise to me.
A possible solution is to use function descriptors. See FDESC_EXPR and
ASM_OUTPUT_FDESC. So now w
Sergei Organov wrote:
-and functions are removed. This may result in undefined references
+and functions. This may result in undefined references
Thanks. I checked in the patch.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
Eric Botcazou wrote:
The HP-UX port on the IA-64 architecture defines the MEMBER_TYPE_FORCES_BLK
macro with this comment:
Steve Ellcey defined MEMBER_TYPE_FORCES_BLK when he first implemented
the ia64-hpux port. At the time, I mentioned using PARALLELs was a
better solution, but this was a s
Gunther Nikl wrote:
A few LINK_SPEC definitions contain a "%{Wl,*:%*}" sequence.
There is no need to match -Wl options in LINK_SPEC, as it is handled by
the gcc.c driver. The driver support was added in gcc-2.5.8. I believe
all of these LINK_SPEC checks for -Wl are obsolete code from gcc-2.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anyone,
I'm having problems with building a release.
~make -C gcc gnatlib-shared
This seems to be broken.
I've attached a small log of the problem (last 50 lines).
The source package, I've tried to make myself can be gotten here:
http://suppor
> From: Giovanni Bajo <[EMAIL PROTECTED]>
>> Diego Novillo <[EMAIL PROTECTED]> wrote:
>>> There has been some opposition in the past about allowing conditions in
>>> asserts to be used as hints to the optimizers. In fact, I would like to
>>> know if there is a current statement of purpose about thi
I am interested in reading the actual grammar files used for parsing C
and C++ programming languages inside gcc. Where are these files located?
Stephen
On Jun 30, 2005, Geoff Keating <[EMAIL PROTECTED]> wrote:
> Does anyone mind if I update libtool to the latest released version,
> 1.5.18, and regenerate everything with automake 1.9.5?
I'm pretty sure the latest released version would introduce some
regressions for features that we added to the
On Jun 29, 2005, "Dave Korn" <[EMAIL PROTECTED]> wrote:
> In fact, doesn't this suggest that in _most_ circumstances, *saturation*
> would be the best behaviour?
If that's for user-introduced overflows, it could be useful in some
cases, but I wouldn't go as far as `most'.
For compiler-introduc
On Jun 29, 2005, Olivier Galibert <[EMAIL PROTECTED]> wrote:
> char x = (char)((unsigned char)y + (unsigned char)z)
> is too ugly to live.
Yeah, indeed, one shouldn't assume char is signed :-) :-)
(strictly speaking, you don't, but I thought this would be funny so I
went ahead and posted it)
Diego Novillo <[EMAIL PROTECTED]> wrote:
>> There has been some opposition in the past about allowing conditions in
>> asserts to be used as hints to the optimizers. In fact, I would like to
>> know if there is a current statement of purpose about this. That is,
would
>> there be strong opposition
On Fri, Jul 01, 2005 at 08:16:19PM +0200, Giovanni Bajo wrote:
> Paul Schlie <[EMAIL PROTECTED]> wrote:
>
> > Where then the programmer could then choose
> > to warrant it by preconditioning the loop:
> >
> > assert((x < y) && ((y - x) % 4)); // which could throw an exception.
> >
> > for ((i
Paul Schlie <[EMAIL PROTECTED]> wrote:
> Where then the programmer could then choose
> to warrant it by preconditioning the loop:
>
> assert((x < y) && ((y - x) % 4)); // which could throw an exception.
>
> for ((i = x; i < y; i++){ ... }
There has been some opposition in the past about allow
On 01/07/2005, at 7:43 AM, Kelley Cook wrote:
Does anyone mind if I update libtool to the latest released
version, 1.5.18, and regenerate everything with automake 1.9.5?
Sounds great if you can get it to work.
I actually have this completely working for the GCC part of the tree,
I thi
> From: Gabriel Dos Reis <[EMAIL PROTECTED]>
> | Paul Schlie <[EMAIL PROTECTED]> writes:
> | As in general it seems that as the compiler knows what it needs to know to
> | enable ideal loop optimization, why not simply have it assert: if it knew x,
> | then it could do y? For example, if given som
On Jul 1, 2005, at 8:51 AM, Paul Schlie wrote:
As in general it seems that as the compiler knows what it needs to
know to
enable ideal loop optimization, why not simply have it assert: if
it knew x,
then it could do y? For example, if given something like:
for (i = x; i < y; i++){ ... }
Paul Schlie <[EMAIL PROTECTED]> writes:
| As in general it seems that as the compiler knows what it needs to know to
| enable ideal loop optimization, why not simply have it assert: if it knew x,
| then it could do y? For example, if given something like:
|
| for (i = x; i < y; i++){ ... }
|
[ please Cc: me ]
Hi Geoff,
* Geoff Keating wrote on Fri, Jul 01, 2005 at 03:37:07AM CEST:
> On 30/06/2005, at 6:26 PM, David Edelsohn wrote:
>
> >Geoff> Does anyone mind if I update libtool to the latest released version,
> >Geoff> 1.5.18, and regenerate everything with automake 1.9.5?
> >
> >
As in general it seems that as the compiler knows what it needs to know to
enable ideal loop optimization, why not simply have it assert: if it knew x,
then it could do y? For example, if given something like:
for (i = x; i < y; i++){ ... }
Where it may not be known statically if x < y, or wha
Index: invoke.texi
===
RCS file: /cvsroot/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.637
diff -u -r1.637 invoke.texi
--- invoke.texi 15 Jun 2005 12:53:41 - 1.637
+++ invoke.texi 1 Jul 2005 14:52:13 -
@@ -5225,7 +5
Does anyone mind if I update libtool to the latest released version,
1.5.18, and regenerate everything with automake 1.9.5?
Sounds great if you can get it to work.
I had experimented with doing it earlier in the year, before Paolo completely redid the
libjava Makefile.am to compile directorie
> Even on mainline?
No, one of our branches.
> See PR debug/21946 and
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00312.html.
> Var-tracking is very broken in that it doesn't care about register
> modes, but what I have comitted should at least prevent bogus dwarf2
> location list generation.
On Fri, 2005-07-01 at 11:50 +0200, Jakub Jelinek wrote:
> On Thu, Jun 30, 2005 at 09:25:47PM -0400, DJ Delorie wrote:
> >
> > My m32c port is generating tracking notes that look like this:
> >
> > (var_location 0x2a95758dd0 (parallel [
> > (expr_list:REG_DEP_TRUE (reg/v:SI 0 r0 [orig:
On Thu, Jun 30, 2005 at 07:17:24PM -0700, Geoff Keating wrote:
> OK. I don't want to update newlib to current tools; that would take
> too long and I don't have the ability to test the result. Nor am I
> very enthusiastic about updating, for instance, gdb.
GDB doesn't use libtool, and now us
On Thu, Jun 30, 2005 at 09:25:47PM -0400, DJ Delorie wrote:
>
> My m32c port is generating tracking notes that look like this:
>
> (var_location 0x2a95758dd0 (parallel [
> (expr_list:REG_DEP_TRUE (reg/v:SI 0 r0 [orig:123 remainder_size ]
> [123])
> (const_int 0 [0x0])
Daniel Berlin wrote:
On Thu, 2005-06-30 at 17:17 -0700, James E Wilson wrote:
Their web pages primarily talk about the 64-bit performance on AMD
systems. Maybe they aren't well tuned for 32-bit performance and/or
Intel parts. Anyways, from what Daniel Berlin mentioned, it may be that
the t
On Fri, Jul 01, 2005 at 10:45:19AM +0200, Etienne Lorrain wrote:
> The result of this funtion is 1, is there a C lawyer around?
The parameter is treated as unsigned* since an array is converted to
a pointer when passed through a function.
C99 says in 6.7.5.3:
[#7] A declaration of a parame
Etienne Lorrain writes:
> The result of this funtion is 1, is there a C lawyer around?
>
> $ cat tmp.c
> unsigned fct (unsigned array[10])
> {
> return sizeof(array) / sizeof(array[0]);
> }
This is 6.7.5.3, Para. 7.
Andrew.
Vladimir Makarov wrote:
I heard a lot of this compiler and expected a better results for it.
Using -O2 -mtune=nocona for gcc4 and -O2 -mtune=em64t for open64 on
em64t machine in 32-bit mode, I found preliminarily that pathscale
compiler generates about 10% worse and 30% larger code (text segm
The result of this funtion is 1, is there a C lawyer around?
$ cat tmp.c
unsigned fct (unsigned array[10])
{
return sizeof(array) / sizeof(array[0]);
}
$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/m
> None of the machines I tried even get that far in an ada bootstrap.
x86 has been reported to be buildable now.
on x86-64, there are one or two pending patches (posted), but building
at -O0 or disable -fwrapv should also work around the failures.
> Probably something in the ada frontend is missi
37 matches
Mail list logo
