How can I register gcc build status for HP-UX 11i
I successfully installed gcc3.4.4 & gcc 4.0.0 for hppa64-hp-hpux11.11
but therer are no build status in http://gcc.gnu.org/gcc-3.4/buildstat.html &
http://gcc.gnu.org/gcc-4.0/buildstat.html
And how can I make results for gcc.xxx testsuite like
h
Gabriel Dos Reis wrote:
That is depressing :-/
cheer up there are worse things in life :-)
I provided quotes in
http://gcc.gnu.org/ml/gcc/2005-12/msg00644.html
-- Gaby
Yes, indeed your quotes were clear. An interesting issue is what is
the meaning of "documentation" in a formal sta
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >Robert Dewar <[EMAIL PROTECTED]> writes:
| >
| >| >However, we have an obligation to define what those mappings are.
| >| >
| >| Why?
| >
| >Because it is an implementation-defined behaviour and we have to
| >document how the
Gabriel Dos Reis wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
| >However, we have an obligation to define what those mappings are.
| >
| Why?
Because it is an implementation-defined behaviour and we have to
document how the choice is made.
-- Gaby
OK, I take your word for it, I remembe
> It was because I had decided to expose the registers as %al, %ah,
> ... %bl, %bh, ... instead of the customary %[e]ax and friends.
I originally did this for the m32c port (which has hi/low pairs like
the i386) but discovered that reload always allocates registers in
UNITS_PER_WORD chunks, and
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Nobody disagree with that, of course (in fact, we discussed a bit that
| specific point with Chris time ago, when probably he wanted to avail
| himself of ordering to improve some bits of debug mode). Only, I become
| nervous when I read sentences like "
Andrew Pinski <[EMAIL PROTECTED]> writes:
[...]
| We don't document the C++ implementation behavior because well no one
| cares enough to do it.
That is largely untrue
http://gcc.gnu.org/ml/gcc/2005-06/msg01162.html
(assuming you read that thread, I discussed the issue with some
committee
Andrew Haley <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis writes:
| > Robert Dewar <[EMAIL PROTECTED]> writes:
| >
| > | >However, we have an obligation to define what those mappings are.
| > | >
| > | Why?
| >
| > Because it is an implementation-defined behaviour and we have to
| > do
Gabriel Dos Reis wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| So please don't take my comments as supporting dubious optimizations
| of pointer arithmetic.
|
| For me the only practical acceptable implementation of pointers in C
| is to use lineary addresses as integers, and imple
Gabriel Dos Reis wrote:
>| Humpf! Can people please cite exact paragraphs of the relevant
>| Standards? Otherwise, I think we are just adding to the confusion. For
>| example, in my reading of C99 6.5.9 and C++03 5.10 pointers *can* be
>| compared for equality and discussing separately and correct
Gabriel Dos Reis writes:
> Robert Dewar <[EMAIL PROTECTED]> writes:
>
> | >However, we have an obligation to define what those mappings are.
> | >
> | Why?
>
> Because it is an implementation-defined behaviour and we have to
> document how the choice is made.
Can you state some language
Robert Dewar <[EMAIL PROTECTED]> writes:
| Paolo Carlini wrote:
|
| >chris jefferson wrote:
| >
| >
| >>>Right, but that's the point. "doing arithmetic on arbitrary pointer"
| >>>values is
| >>>not defined, it is not even defined to compare two pointers pointing
| >>>to two
| >>>different objects
On Dec 21, 2005, at 2:43 PM, Gabriel Dos Reis wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
| >However, we have an obligation to define what those mappings are.
| >
| Why?
Because it is an implementation-defined behaviour and we have to
document how the choice is made.
We actually documen
Robert Dewar <[EMAIL PROTECTED]> writes:
| >However, we have an obligation to define what those mappings are.
| >
| Why?
Because it is an implementation-defined behaviour and we have to
document how the choice is made.
-- Gaby
Paolo Carlini <[EMAIL PROTECTED]> writes:
| chris jefferson wrote:
|
| >>Right, but that's the point. "doing arithmetic on arbitrary pointer"
| >>values is
| >>not defined, it is not even defined to compare two pointers pointing
| >>to two
| >>different objects.
| >>
| >While that is true accordi
| Yes, but the only defined semantics of these conversions is that you
| get the same
| pointer back, you cannot say anything else about the values. If you
You get the same pointer back, *when* you've done a round trip.
For
pointer type -> integer type
or
integer type -> pointer type
Paolo Carlini wrote:
chris jefferson wrote:
Right, but that's the point. "doing arithmetic on arbitrary pointer"
values is
not defined, it is not even defined to compare two pointers pointing
to two
different objects.
While that is true according to the standard, I believe that on
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| So please don't take my comments as supporting dubious optimizations
| of pointer arithmetic.
|
| For me the only practical acceptable implementation of pointers in C
| is to use lineary addresses as integers, and implemnet wrap around
| arithmeti
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >It highly depends on what you define to be pointer arithmetic.
| >
| >Given the conversions
| >
| > pointer -> integer type
| > integer type -> pointer
| > T* -> U*
| >
| Yes, but the only defined semantics of these con
chris jefferson wrote:
>>Right, but that's the point. "doing arithmetic on arbitrary pointer"
>>values is
>>not defined, it is not even defined to compare two pointers pointing
>>to two
>>different objects.
>>
>While that is true according to the standard, I believe that on most
>systems you can c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think so, at least.
The problem I seem to be having is related to this bit of code in
reload1.c:find_reg():
for (j = 1; j < this_nregs; j++)
{
this_cost += spill_add_cost[regno + j];
if ((TEST_HARD_
Robert Dewar wrote:
> Richard Guenther wrote:
>
>> On Wed, 21 Dec 2005, Andrew Haley wrote:
>>
>>
>>
>>> Richard Guenther writes:
>>> > > The problem in this PR is that code like in the testcase (from
>>> > OpenOffice) assumes that pointer overflow is defined. As the
>>> > standard does not talk
Gabriel Dos Reis wrote:
with no more qualifications (this definition is slightly different in
some nearby languages), it is slippery to found optimizations on
"pointer overflows."
Well I think unfortunately the standard does allow such "optimizations",
but that does
not mean it is a good th
Robert Dewar <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| >you can (equality) compare a pointer to NULL -- which does not even
| >happen to designate an object.
| >
| Well accurately, you can compare pointers, its not illegal, but the
| result of
| comparing pointers to separately al
Gabriel Dos Reis wrote:
It highly depends on what you define to be pointer arithmetic.
Given the conversions
pointer -> integer type
integer type -> pointer
T* -> U*
Yes, but the only defined semantics of these conversions is that you get
the same
pointer back, you cannot say anythin
Gabriel Dos Reis wrote:
you can (equality) compare a pointer to NULL -- which does not even
happen to designate an object.
Well accurately, you can compare pointers, its not illegal, but the
result of
comparing pointers to separately allocated objects is undefined.
[...]
| One way to thi
Robert Dewar <[EMAIL PROTECTED]> writes:
| Richard Guenther wrote:
|
| >The problem in this PR is that code like in the testcase (from OpenOffice)
| >assumes that pointer overflow is defined. As the standard does not talk
| >about wrapping pointer semantics at all (at least I couldn't find anyth
Robert Dewar <[EMAIL PROTECTED]> writes:
| Richard Guenther wrote:
|
| >On Wed, 21 Dec 2005, Andrew Haley wrote:
| >
| >
| >>Richard Guenther writes:
| >> > > The problem in this PR is that code like in the testcase (from
| >> > OpenOffice) assumes that pointer overflow is defined. As the
| >> >
This was meant for gcc-patches of course, sorry.
http://gcc.gnu.org/ml/gcc/2005-12/msg00633.html
Paolo
This patch splits simplify_and_const_int and simplify_shift_const
into two functions (each): one that tries to simplify and returns
NULL_RTX if it cannot produce anything, and one that has the same
calling convention as before. In the meanwhile, I made them
produce new RTXen instead of substituti
Hello,
during expansion of expressions, gimplification creates a lot of temporary
variables. VAR_DECLs are fairly large (88 bytes on i686), and
additionally an annotation (44 bytes on i686) are allocated for each of
them (some of them even get names, for additional ~50 bytes of memory
each). Thi
Etienne Lorrain wrote:
Hello,
A lot of people (me too) write this kind of code:
struct param1_str *param1;
struct param2_str *param2;
struct param3_str *param3;
error = treat_alpha (param1, param2, param3);
if (error)
printf ("treat_alpha failed error %d, param1 = %p, "
Hello,
A lot of people (me too) write this kind of code:
struct param1_str *param1;
struct param2_str *param2;
struct param3_str *param3;
error = treat_alpha (param1, param2, param3);
if (error)
printf ("treat_alpha failed error %d, param1 = %p, "
"param2 = %p, param3 = %p
Richard Guenther wrote:
On Wed, 21 Dec 2005, Andrew Haley wrote:
Richard Guenther writes:
>
> The problem in this PR is that code like in the testcase (from
> OpenOffice) assumes that pointer overflow is defined. As the
> standard does not talk about wrapping pointer semantics at all (at
Richard Guenther wrote:
The problem in this PR is that code like in the testcase (from OpenOffice)
assumes that pointer overflow is defined. As the standard does not talk
about wrapping pointer semantics at all (at least I couldn't find anything
about that), how should we treat this?
How co
Richard Guenther writes:
> On Wed, 21 Dec 2005, Andrew Haley wrote:
>
> > Richard Guenther writes:
> > >
> > > The problem in this PR is that code like in the testcase (from
> > > OpenOffice) assumes that pointer overflow is defined. As the
> > > standard does not talk about wrapping
On Wed, 21 Dec 2005, Andrew Haley wrote:
> Richard Guenther writes:
> >
> > The problem in this PR is that code like in the testcase (from
> > OpenOffice) assumes that pointer overflow is defined. As the
> > standard does not talk about wrapping pointer semantics at all (at
> > least I coul
Richard Guenther writes:
>
> The problem in this PR is that code like in the testcase (from
> OpenOffice) assumes that pointer overflow is defined. As the
> standard does not talk about wrapping pointer semantics at all (at
> least I couldn't find anything about that), how should we treat
>
The problem in this PR is that code like in the testcase (from OpenOffice)
assumes that pointer overflow is defined. As the standard does not talk
about wrapping pointer semantics at all (at least I couldn't find anything
about that), how should we treat this?
Thanks for any advice,
Richard.
39 matches
Mail list logo
