Hi all,
I did this once in the past but lost my transscript ... What was the
recommended way to get a sparc64-gnu-linux (or other biarch) compiler that
defaults to -m32? Is there a config or was the way to patch the linux64.h in
the arch config dir?
Thanks in advance,
--
René Rebe - Rubensst
On Wednesday 08 June 2005 09:56, René Rebe wrote:
> Hi all,
>
> I did this once in the past but lost my transscript ... What was the
> recommended way to get a sparc64-gnu-linux (or other biarch) compiler that
> defaults to -m32? Is there a config or was the way to patch the linux64.h
> in the arch
HI again,
On Wednesday 08 June 2005 09:56, René Rebe wrote:
> I did this once in the past but lost my transscript ... What was the
> recommended way to get a sparc64-gnu-linux (or other biarch) compiler that
> defaults to -m32? Is there a config or was the way to patch the linux64.h
> in the arch
On Wed, Jun 08, 2005 at 10:50:16AM +0200, Andreas Jaeger wrote:
> On Wednesday 08 June 2005 09:56, René Rebe wrote:
> > Hi all,
> >
> > I did this once in the past but lost my transscript ... What was the
> > recommended way to get a sparc64-gnu-linux (or other biarch) compiler that
> > defaults to
"Joel Sherrill <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> writes:
> I'm happy to anounce that Andreas Schwab <[EMAIL PROTECTED]>
> as the new m68k port maintainer.
Thank you for the appointment. I have installed this patch to
MAINTAINERS.
Andreas.
2005-06-08 Andreas Schwab <[EMAIL PROTECTED]>
The inclusion of this patch:
2005-06-07 Zdenek Dvorak <[EMAIL PROTECTED]>
* tree-ssa-address.c: New file.
* Makefile.in (tree-ssa-address.o): Add.
* expr.c (expand_expr_real_1): Do not handle REF_ORIGINAL on
INDIRECT_REFs. Handle TARGET_MEM_REFs.
...
c
void pig(void) __attribute__ ((long_call));
void pig(void)
{
}
Yes, that's the way it's currently coded.
The problem, it seems to me, is that we want to fault:
void pig(void) __attribute__ ((long_call));
...
void pig(void);
and
void pig(void);
On Wednesday 08 June 2005 12:01, Nick Burrett wrote:
> $ ./cc1 -quiet test.c -mthumb -O2
> ../../bug.c: In function ‘foo’:
> ../../bug.c:3: internal compiler error: in create_mem_ref, at
> tree-ssa-address.c:585
> Please submit a full bug report,
^^^
;-)
And some mor
Hi,
The HP-UX port on the IA-64 architecture defines the MEMBER_TYPE_FORCES_BLK
macro with this comment:
/* This needs to be set to force structure arguments with a single
integer field to be treated as structures and not as the type of
their field. Without this a structure with a single
On Wed, 2005-06-08 at 11:11, Jani Monoses wrote:
> >>void pig(void) __attribute__ ((long_call));
> >>void pig(void)
> >>{
> >>}
> >
> > Yes, that's the way it's currently coded.
> >
> > The problem, it seems to me, is that we want to fault:
> >
> > void pig(void) __attribute__ ((long_cal
Is there anything tricky that prevents an easy implementation?
Yes, internally the routine that's doing the comparison can't
distinguish declarations from definitions. We need to diagnose
Is the routine arm_comp_type_attributes() in gcc/config/arm/arm.c by any chance?
conflicting declarati
On Wed, 2005-06-08 at 11:51, Jani Monoses wrote:
> >>Is there anything tricky that prevents an easy implementation?
> >
> > Yes, internally the routine that's doing the comparison can't
> > distinguish declarations from definitions. We need to diagnose
>
> Is the routine arm_comp_type_attributes
void __attribute__ ((long_call)) pig(void)
{
}
Ok thanks, with such change to the definition the file compiles.
I didn't know one can attribute definitions too, and info gcc says:
"
The keyword `__attribute__' allows you to specify special attributes
when making a declaration.
"
So I suppos
> "Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]> writes:
Nathanael> Paul Koning wrote:
>>> "Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]>
>>> writes:
>>
Nathanael> * pdp11-*-* (generic only) Useless generic.
>> I believe this one generates DEC (as opposed to BSD) callin
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>
>> - yes, it certainly enables an implementation to generate more efficient
>> code which has no required behavior; so in effect basically produce more
>> efficient programs which don't reliably do anything in particular; which
>>
Original Message
>From: Paul Schlie
>Sent: 08 June 2005 14:40
> - Can you give an example of an operation which may yield an undefined
> non-deterministic result which is reliably useful for anything?
Random number generation?
cheers,
DaveK
--
Can't think of a witty .s
> From: Dave Korn <[EMAIL PROTECTED]>
> Original Message
>> From: Paul Schlie
>> Sent: 08 June 2005 14:40
>
>> - Can you give an example of an operation which may yield an undefined
>> non-deterministic result which is reliably useful for anything?
>
> Random number generation?
- wh
Original Message
>From: Paul Schlie
>Sent: 08 June 2005 14:49
>> From: Dave Korn <[EMAIL PROTECTED]>
>> Original Message
>>> From: Paul Schlie
>>> Sent: 08 June 2005 14:40
>>
>>> - Can you give an example of an operation which may yield an undefined
>>> non-deterministic result
Paul Schlie wrote:
From: Dave Korn <[EMAIL PROTECTED]>
Original Message
From: Paul Schlie
Sent: 08 June 2005
- Can you give an example of an operation which may yield an undefined
non-deterministic result which is reliably useful for anything?
Random number generation?
rando
Dave Korn wrote:
I didn't say "Pseudo random number generation". I said "Random number
generation".
which once again has nothing whatever to do with non-determinism.
TO illustrate this, suppose I have a language which has sets of
integers. I have an operator ARB whose semantics is to selec
Paul Schlie wrote:
What's silly, is claiming that such operations are bit exact when even
something as basic as their representational base radix number systems
isn't even defined by the standard, nor need necessarily be the same
between different FP types; thereby an arbitrary value
- Can you give an example of an operation which may yield an undefined
non-deterministic result which is reliably useful for anything?
Hm. int foo (const char *x, int y) { return printf (x, y); }
Lassi
--
If you would know the value of money, go try to borrow some.
--Ben Franklin
Hello,
> On Wednesday 08 June 2005 12:01, Nick Burrett wrote:
> > $ ./cc1 -quiet test.c -mthumb -O2
> > ../../bug.c: In function ?foo?:
> > ../../bug.c:3: internal compiler error: in create_mem_ref, at
> > tree-ssa-address.c:585
> > Please submit a full bug report,
>
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| You are really just digging yourself into a hole here. It is clear
| that you know very little about floating-point arithmetic.
[...]
| More complete nonsense.
[...]
| Are you saying they are all idiots and you know better, or are you
| willing
> From: Robert Dewar <[EMAIL PROTECTED]>
> Date: Wed, 08 Jun 2005 10:16:23 -0400
> To: Paul Schlie <[EMAIL PROTECTED]>
> Cc: Florian Weimer <[EMAIL PROTECTED]>, Andrew Pinski <[EMAIL PROTECTED]>,
> GCC List , <[EMAIL PROTECTED]>
> Subject: Re: Ada front-end depends on signed overflow
>
> You are re
Original Message
>From: Paul Schlie
>Sent: 08 June 2005 15:53
>> From: Robert Dewar
>> There is nothing imprecise about IEEE floating-point operations
>
> - agreed, however nor is it mandated by most language specifications,
> so seemingly irrelevant.
I refer you to "Annex F (normativ
Paul Schlie wrote on 08/06/2005 17:53:04:
>
> - I would have if someone could provide a concrete example of an
undefined
> behavior which produces a reliably useful/predictable result.
>
Well this is a simple hackery quiz, which is irrelevant to GCC.
1: int a, b;
2: int f()
Paul Schlie wrote:
From: Robert Dewar <[EMAIL PROTECTED]>
You keep saying this over and over, but it does not make it true. Once
again, the whole idea of making certain constructs undefined, is to
ensure that efficient code can be generated for well defined constructs.
- Can you give an exampl
On Wed, Jun 08, 2005 at 10:53:04AM -0400, Paul Schlie wrote:
> > From: Robert Dewar <[EMAIL PROTECTED]>
> > There is nothing imprecise about IEEE floating-point operations
>
> - agreed, however nor is it mandated by most language specifications,
> so seemingly irrelevant.
In real life, there ar
Consider the (two) case(s)
double foo(double) __attribute__((sseregparm));
static double bar(double) __attribute__((sseregparm));
static double bar(double x) { return x; }
now, with -mno-sse we have the following choices for call
to function foo:
1 Emit the call with SSE arguments regardless
The GCC 4.0.1 RC1 prerelease is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
Please test these tarballs, and let me know about showstoppers.
I'm aware of the request to fix PR 21364 before the final release, and
I'll be looking into that.
I'll also consider patches
On Wednesday 08 June 2005 18:57, Mark Mitchell wrote:
> The GCC 4.0.1 RC1 prerelease is available here:
>
>ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
>
> Please test these tarballs, and let me know about showstoppers.
already done a changelog in advance?
i am looking for further o
On Jun 8, 2005, at 12:57 PM, Mark Mitchell wrote:
The GCC 4.0.1 RC1 prerelease is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
Please test these tarballs, and let me know about showstoppers.
Can I revert a patch which I accidentally applied with another patch?
See
> From: Joe Buck <[EMAIL PROTECTED]>
>> On Wed, Jun 08, 2005 at 10:53:04AM -0400, Paul Schlie wrote:
>>> From: Robert Dewar <[EMAIL PROTECTED]>
>>> There is nothing imprecise about IEEE floating-point operations
>>
>> - agreed, however nor is it mandated by most language specifications,
>> so se
Andrew Pinski wrote:
On Jun 8, 2005, at 12:57 PM, Mark Mitchell wrote:
The GCC 4.0.1 RC1 prerelease is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
Please test these tarballs, and let me know about showstoppers.
Can I revert a patch which I accidentally applied w
> From: Bernd Schmidt <[EMAIL PROTECTED]>
> Paul Schlie wrote:
>>> From: Robert Dewar <[EMAIL PROTECTED]>
>>> You keep saying this over and over, but it does not make it true. Once
>>> again, the whole idea of making certain constructs undefined, is to
>>> ensure that efficient code can be generate
On Jun 8, 2005, at 1:24 PM, Mark Mitchell wrote:
Andrew Pinski wrote:
On Jun 8, 2005, at 12:57 PM, Mark Mitchell wrote:
The GCC 4.0.1 RC1 prerelease is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
Please test these tarballs, and let me know about showstoppers.
Can
On Wed, Jun 08, 2005 at 06:36:49PM +0200, Richard Guenther wrote:
> now, with -mno-sse we have the following choices for call
> to function foo:
With -mno-sse and explicit use of sseregparm, error at compile time.
This is no different from any other ISA related compile time error
that we generate.
> From: Michael Veksler <[EMAIL PROTECTED]>
>> Paul Schlie wrote on 08/06/2005 17:53:04:
>> - I would have if someone could provide a concrete example of an
>> undefined behavior which produces a reliably useful/predictable result.
>>
> Well this is a simple hackery quiz, which is irrelevant to
I noticed that vectors are always aligned based on their size, i.e. an
8 byte vector has an aligment of 8 bytes, 16 byte vectors an alignment
of 16, a 256 byte vector an alignment of 256, etc.
Is this really intended?
I looked in stor-layout.c and found:
/* Always naturally align vectors
Paul Schlie <[EMAIL PROTECTED]> wrote on 08/06/2005 21:16:46:
> > From: Michael Veksler <[EMAIL PROTECTED]>
> >> Paul Schlie wrote on 08/06/2005 17:53:04:
> >> - I would have if someone could provide a concrete example of an
> >> undefined behavior which produces a reliably useful/predicta
Hi,
This adds a link in "Further readings" to the Wikipedia page
about IEEE 754r. Seems interesting enough...
The change to the existing link is necessary to make the page
render without unnecessary spaces before "Differences".
OK?
Gr.
Steven
Index: htdocs/readings.html
=
On Wed, Jun 08, 2005 at 12:50:32PM -0700, Steve Ellcey wrote:
> I noticed that vectors are always aligned based on their size, i.e. an
> 8 byte vector has an aligment of 8 bytes, 16 byte vectors an alignment
> of 16, a 256 byte vector an alignment of 256, etc.
>
> Is this really intended?
Yes.
> On Wed, Jun 08, 2005 at 12:50:32PM -0700, Steve Ellcey wrote:
> > I noticed that vectors are always aligned based on their size, i.e. an
> > 8 byte vector has an aligment of 8 bytes, 16 byte vectors an alignment
> > of 16, a 256 byte vector an alignment of 256, etc.
> >
> > Is this really inten
Can somebody suggest a place to start looking for
why the libgcc_s.so built by crosstool's gcc-3.4 can't handle
exceptions from apps built by fc3's gcc-3.4?
The C++ program
#include
void foo() throw (int) {
std::cout << "In foo()" << std::endl;
throw 1;
}
int main() {
try {
foo();
} catc
On Wed, Jun 08, 2005 at 03:57:26PM -0700, Daniel Kegel wrote:
> Can somebody suggest a place to start looking for
> why the libgcc_s.so built by crosstool's gcc-3.4 can't handle
> exceptions from apps built by fc3's gcc-3.4?
Try diffing the output of configure from building one and the other.
Prob
Daniel Jacobowitz wrote:
Daniel Kegel wrote:
Can somebody suggest a place to start looking for
why the libgcc_s.so built by crosstool's gcc-3.4 can't handle
exceptions from apps built by fc3's gcc-3.4?
Try diffing the output of configure from building one and the other.
Probably some important
Paul Schlie wrote:
- How is it necessary or desirable to define that the result is undefined
vs. being target defined?
What does C say about how a target performs an instruction?
And why shouldn't GCC take advantage of this?
When `try_combine' combines two instructions, it adds the register notes
from the old insns to the new combined insn. It also adds new register
notes calculated from the new insn's clobbers by `recog_for_combine'.
In this process, it (`distribute_notes') suppresses duplicate register
notes, but i
On Jun 6, 2005, at 12:17 PM, Samuel Smythe wrote:
It is well-known that Apple has been a significant provider of GCC
enhancements. But it is also probably now well-known that they have
opted to drop the PPC architecture in favor of an x86-based
architecture. Will Apple continue to contribute t
50 matches
Mail list logo
