George R Goffe <[EMAIL PROTECTED]> writes:
> tail: cannot open `+16c' for reading: No such file or directory
> tail: cannot open `+16c' for reading: No such file or directory
> tail: cannot open `+16c' for reading: No such file or directory
You have the buggy version of coreutils that does not re
Joe Buck wrote:
Here's a simple example.
int blah(int);
int func(int a, int b) {
if (b >= 0) {
int c = a + b;
int count = 0;
for (int i = a; i <= c; i++)
count++;
blah(count);
}
>>
After reading many messages on the subject of overflow
of signed integral values, I am inclined to think that the
standard was wrong to say that int overflow is undefined.
Of course this definition improves performance, but at
what cost? At the cost of program stability?
If the programmer wan
Michael Veksler wrote:
If the programmer wants a robust application,
then casting to unsigned must be present for almost any
usage of int.
If you have a variable in your program that is signed but must
always be in the range of int, then int is the appropriate
representation. If the pressure i
I continued to work on the support for named address spaces in GCC. I
managed to move much of the managing code for the namespace attribute
into the create funtions of tree nodes, so in most cases, only the
language frontends need to assign and check the named address spaces.
I moved to creation o
> This is unlike aliasing, when most lines of code out there,
> did not break aliasing rules (even before they were
> introduced).
Are you sure? IIRC -fstrict-aliasing was once enabled at -O2 and then
disabled to give people more time to fix their code.
--
Eric Botcazou
On Tue, Jun 28, 2005 at 11:59:15PM -0500, Steven J. Hill wrote:
> I have discovered what appears to be an optimization bug with '-Os'
> in GCC-4.1.0 for the MIPS architecture. It appears that functions
> which are declared as 'inline' are being ignored and instead turned
> into to function calls ..
Robert Dewar <[EMAIL PROTECTED]> wrote on 29/06/2005 11:42:07:
> Michael Veksler wrote:
>
> > If the programmer wants a robust application,
> > then casting to unsigned must be present for almost any
> > usage of int.
>
> If you have a variable in your program that is signed but must
> always
Michael Veksler wrote:
This is right to some extent, and I referred to it in my original
mail. I claim that it is easier to write a code that checks these cases
after the overflow, rather than before. I also claim that checking
overflows (as implied by the standard) results in almost pure
unsign
On Wed, 2005-06-29 at 11:32 +0300, Michael Veksler wrote:
> This is unlike aliasing, when most lines of code out there,
> did not break aliasing rules (even before they were
> introduced). Int overflow is violated by most lines of
> code I have seen (it is very uncommon to find code that
> asserts
"Steven J. Hill" <[EMAIL PROTECTED]> writes:
> I have discovered what appears to be an optimization bug with '-Os'
> in GCC-4.1.0 for the MIPS architecture. It appears that functions
> which are declared as 'inline' are being ignored and instead turned
> into to function calls which is breaking th
Eric Botcazou <[EMAIL PROTECTED]> wrote on 29/06/2005 11:49:24:
> > This is unlike aliasing, when most lines of code out there,
> > did not break aliasing rules (even before they were
> > introduced).
>
> Are you sure? IIRC -fstrict-aliasing was once enabled at -O2 and then
> disabled to give
Theodore Papadopoulo wrote:
So unless you do arithmetics or combinatorics, most of the uses of
"wide" (ie > 32b) integral types semantically (ie in the programmer's
mind) assume that overflow does not happen in practise in the program.
I think that's probably right. And in the context of this
> Limitations are:
> * All pointer have Pmode size.
The ability to have various pointer widths would be nice too.
Richard Henderson wrote:
Not a bug. The inline marker is merely suggestive. You told
the compiler to optimize for size, and it is doing that.
If you absolutely have to have the function inlined, then you
need to use __attribute__((__always_inline__)).
This makes sense, but I also have a bin
On Wed, 2005-06-29 at 07:44 -0500, Steven J. Hill wrote:
> Richard Henderson wrote:
> >
> > Not a bug. The inline marker is merely suggestive. You told
> > the compiler to optimize for size, and it is doing that.
> >
> > If you absolutely have to have the function inlined, then you
> > need to
> Overall, I guess I still simply believe the the first rule of optimization
> is to preserve existing semantics unless explicitly authorized otherwise,
> and then only if accompanied with corresponding warnings for all potentially
> behavior altering assumptions applied.
It is, you just believe
Original Message
>From: Robert Dewar
>Sent: 29 June 2005 13:14
> Theodore Papadopoulo wrote:
>
>> So unless you do arithmetics or combinatorics, most of the uses of
>> "wide" (ie > 32b) integral types semantically (ie in the programmer's
>> mind) assume that overflow does not happen in pr
On Wed, Jun 29, 2005 at 10:47:40AM +0200, Martin Koegler wrote:
> NAMESPACE(EEPROM);
> NAMESPACE(LORAM);
>
> (I know, that the NAMESPACE is not the correct naming, but named
> address space is a bit too long. Any suggestions?)
ADDRSPACE? Named is implicit, since you provided a name.
BTW, you ma
Dave Korn wrote:
In fact, doesn't this suggest that in _most_ circumstances, *saturation*
would be the best behaviour?
Actually I think a handlable exception, a la Ada, is the best solution.
Whether saturation is appropriate is really problem dependent. If you
are counting the number of prim
On Tue, 28 Jun 2005, Joe Buck wrote:
There is no such assumption. Rather, we assume that overflow does not
occur about what happens on overflow. Then, for the case where overflow
does not occur, we get fast code. For many cases where overflow occurs
with a 32-bit int, our optimized program be
> From: Daniel Berlin <[EMAIL PROTECTED]>
>> Overall, I guess I still simply believe the the first rule of optimization
>> is to preserve existing semantics unless explicitly authorized otherwise,
>> and then only if accompanied with corresponding warnings for all potentially
>> behavior altering a
> "Nicholas" == Nicholas Nethercote <[EMAIL PROTECTED]> writes:
Nicholas> This point about 33-bit machines is interesting because it
Nicholas> raises an optimisation scenario that hasn't been mentioned
Nicholas> so far.
Nicholas> Consider doing 32-bit integer arithmetic on 64-bit machines
Martin Koegler wrote:
I continued to work on the support for named address spaces in GCC. I
managed to move much of the managing code for the namespace attribute
into the create funtions of tree nodes, so in most cases, only the
language frontends need to assign and check the named address space
DJ Delorie wrote:
Limitations are:
* All pointer have Pmode size.
The ability to have various pointer widths would be nice too.
I would agree with this too. It would be very useful, e.g. for the AVR port.
Eric
Hello everyone,
In 2000, SGI released a GPLed compiler suite.
http://gcc.gnu.org/ml/gcc/2000-05/threads.html#00632
http://web.archive.org/www.sgi.com/newsroom/press_releases/2000/may/linux-ia64.html
I've taken PathScale's source tree (they've removed the IA-64 code
generator, and added an x86/A
> Yes, I am pretty sure. I said "most lines of code", not "most
> applications",
> to indicate the density difference. If each line of code has, e.g., 1%
> chance
> to violate overflow rules, and 0.01% chance to violate aliasing rules,
> then for 10KLOC, you have:
> - probability of 63% to viola
On Tuesday 28 June 2005 14:09, Steven Bosscher wrote:
> On Tuesday 28 June 2005 14:02, Ulrich Weigand wrote:
> > Steven Bosscher wrote:
> > > Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv". Let's
> > > see how big the damage would be ;-)
> >
> > Please make sure to include a 64-bit t
On Wed, Jun 29, 2005 at 03:40:11AM -0400, Paul Schlie wrote:
> > Since you made an incorrect analysis, you draw incorrect conclusions.
>
> - fair enough, however it seems to me that assuming overflow does not occur
> and assuming overflows are trapped are logically equivalent?
No. Assuming overf
Hello,
I'm implementing a tiny vfork/exit implementation using setjmp and
longjmp. Since the function calling setjmp can't return (if you still
want to longjmp to its jmp_buf) I implemented vfork using a statement
expression macro. Here's my implementation of vfork.
jmp_buf *vfork_jmp_buf;
#defin
On Wed, Jun 29, 2005 at 10:34:20AM -0700, Shaun Jackman wrote:
> the statement expression macro? My best idea was to use alloca, but it
> wouldn't look pretty. Can someone confirm that memory allocated with
> alloca would last the lifetime of the function call, and not the
> lifetime of the stateme
Marc Gonzalez-Sigler wrote:
Hello everyone,
I've taken PathScale's source tree (they've removed the IA-64 code
generator, and added an x86/AMD64 code generator), and tweaked the
Makefiles.
I thought some of you might want to take a look at the compiler.
http://www-rocq.inria.fr/~gonzalez/
On Wed, 2005-06-29 at 18:46 +0200, Steven Bosscher wrote:
> On Tuesday 28 June 2005 14:09, Steven Bosscher wrote:
> > On Tuesday 28 June 2005 14:02, Ulrich Weigand wrote:
> > > Steven Bosscher wrote:
> > > > Anyway, I've started a SPEC run with "-O2" vs. "-O2 -fwrapv". Let's
> > > > see how big th
On Wednesday 29 June 2005 20:01, Daniel Berlin wrote:
> So i would advise anyone arguing against turning on -fwrapv simply
> because it doesn't seem to hurt us at O2.
wtf, "doesn't seem to hurt us at -O2". Look again at the 64 bits
numbers! Losing 5% on the fp benchmarks is a serious regression.
On Wed, Jun 29, 2005 at 02:12:40PM +0100, Dave Korn wrote:
> In fact, doesn't this suggest that in _most_ circumstances, *saturation*
> would be the best behaviour?
No, you'd be killing most emulators and a lot of virtual machine
implementations.
char x = (char)((unsigned char)y + (unsigned c
Steven Bosscher wrote:
On Wednesday 29 June 2005 20:01, Daniel Berlin wrote:
So i would advise anyone arguing against turning on -fwrapv simply
because it doesn't seem to hurt us at O2.
wtf, "doesn't seem to hurt us at -O2". Look again at the 64 bits
numbers! Losing 5% on the fp benchmarks
Tom Tromey wrote:
I'm checking this in on the trunk. If I remember I'll put it on the
4.0 branch once it reopens (there are a fair number of patches pending
for it ... I hope it reopens soon).
Mark,
The extended freeze of the 4.0 branch is making things difficult for
libgcj because we ha
On Wed, 29 Jun 2005, Daniel Berlin wrote:
So i would advise anyone arguing against turning on -fwrapv simply
because it doesn't seem to hurt us at O2.
And i'll again point out that the exact opposite is the default in every
other compiler i'm aware of.
Sorry, I couldn't parse those sentences.
Bryce McKinlay wrote:
Mark,
Could we get an exemption from the freeze rules for low-risk, runtime
only libgcj fixes as determined by the libgcj maintainers?
I don't think we want to do that.
First, we're close to a release. We've been waiting on one fix since
Friday, and Jeff Law has p
Vladimir Makarov wrote:
> Marc Gonzalez-Sigler wrote:
>
>> I've taken PathScale's source tree (they've removed the IA-64 code
>> generator, and added an x86/AMD64 code generator), and tweaked the
>> Makefiles.
>>
>> I thought some of you might want to take a look at the compiler.
>>
>> http://www
Isn't it the case that *any* conversion can be stripped for the purpose
of this routine? I get an ICE compiling the Ada RTS a-strfix.adb because
of that. The following seems to fix it, but is it right?
*** tree-ssa-loop-ivopts.c 26 Jun 2005 21:21:32 - 2.82
--- tree-ssa-loop-ivopts.
On 6/29/05, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 29, 2005 at 10:34:20AM -0700, Shaun Jackman wrote:
> > the statement expression macro? My best idea was to use alloca, but it
> > wouldn't look pretty. Can someone confirm that memory allocated with
> > alloca would last the lif
The fortran front-end needs to recognize clog10, clog10f and clog10l a
proper built-ins. Attached patch tries to add them to clog10, under a
new category: DEF_EXT_C99RES_BUILTIN (as suggested by jsm28).
Can someone review this? Is it OK?
Thanks,
François-Xavier
Index: gcc/builtins.def
===
On Wed, 2005-06-29 at 13:39 -0700, Mark Mitchell wrote:
> First, we're close to a release. We've been waiting on one fix since
> Friday, and Jeff Law has promised to fix it today.
The fix is written, I'm just waiting on test results. Someone mucked
up the hpux11 target description (*) which caus
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Bryce McKinlay wrote:
>
> > Mark,
>
> > Could we get an exemption from the freeze rules for low-risk,
> > runtime only libgcj fixes as determined by the libgcj maintainers?
>
> I don't think we want to do that.
>
> First, we're close to a release. W
Hi,
I have a question about the scheduler. Forgive me if I'm totally
missing the point here, this scheduling business is not my thing ;-)
Consider the following snippet that I've derived from PR17808 with a
few hacks in the compiler to renumber insns and dump RTL with all the
dependencies befor
Why is that C++ can't create normal DECL's like everyone else?
Case in point:
(gdb)
unit size
...
addressable used BLK file minimal.c line 194 size unit size
$11 = void
(gdb) y
So we've got a parm decl that if you ask it for the DECL_SIZE, says 0,
but has a TYPE_SIZE of 12 by
On Wed, Jun 29, 2005 at 03:53:18PM -0600, Jeffrey A Law wrote:
> (*) The hpux11 target description assumes that the linker shipped with
> hpux11 supports +init as an option. Well, that may work OK for some
> versions of hpux11, but it certainly doesn't work for hpux11.00 with
> the 990903 version
On Jun 29, 2005, at 3:46 PM, Steven Bosscher wrote:
I have a question about the scheduler. Forgive me if I'm totally
missing the point here, this scheduling business is not my thing ;-)
Consider the following snippet that I've derived from PR17808 with a
few hacks in the compiler to renumber in
Hi Guys,
I don't any feedback but I am having problem sending to [EMAIL PROTECTED] Is
there a trick to send email? I signed up for the mailing list today. Any
suggestion would be helpful.
Best regards,
~Aalok
_
Express yourself
On Wed, 2005-06-29 at 16:17 -0700, Joe Buck wrote:
> On Wed, Jun 29, 2005 at 03:53:18PM -0600, Jeffrey A Law wrote:
> > (*) The hpux11 target description assumes that the linker shipped with
> > hpux11 supports +init as an option. Well, that may work OK for some
> > versions of hpux11, but it cer
On Wed, Jun 29, 2005 at 06:57:12PM -0400, Daniel Berlin wrote:
> I'm going to work around this by using TYPE_SIZE, but it would be nice
> if somebody could explain the purpose for this behavior (if it's a bug,
> i'll file a bug report). I would imagine we don't have truly empty
> things in C++, so
> > I have an hpux11.0 box available, and could run tests of your patch
> > if you like.
> I doubt it would have (or will make) much of a difference at this
> point. I don't think anyone could have predicted the muck-up with
> the arguments passed to ld and the re-bootstrap that had to run
> after
On Wed, 2005-06-29 at 16:55 -0700, Richard Henderson wrote:
> On Wed, Jun 29, 2005 at 06:57:12PM -0400, Daniel Berlin wrote:
> > I'm going to work around this by using TYPE_SIZE, but it would be nice
> > if somebody could explain the purpose for this behavior (if it's a bug,
> > i'll file a bug rep
On Wed, 2005-06-29 at 14:01 -0400, Vladimir Makarov wrote:
> Marc Gonzalez-Sigler wrote:
>
> > Hello everyone,
> >
> >
> > I've taken PathScale's source tree (they've removed the IA-64 code
> > generator, and added an x86/AMD64 code generator), and tweaked the
> > Makefiles.
> >
> > I thought so
On Jun 29, 2005, at 5:44 PM, Richard Kenner wrote:
Isn't it the case that *any* conversion can be stripped for the purpose
of this routine? I get an ICE compiling the Ada RTS a-strfix.adb
because
of that. The following seems to fix it, but is it right?
This is PR 22212: http://gcc.gnu.org
Shaun Jackman wrote:
Hello,
I'm implementing a tiny vfork/exit implementation using setjmp and
longjmp. Since the function calling setjmp can't return (if you still
want to longjmp to its jmp_buf) I implemented vfork using a statement
expression macro. Here's my implementation of vfork.
jmp_buf
Ada is now broken on the mainline by:
2005-06-28 Paul Brook <[EMAIL PROTECTED]>
* Makefile.in: Set and use UNWIND_H. Install as unwind.h.
* c-decl.c (finish_decl): Call default_init_unwind_resume_libfunc.
* except.c (add_ehspec_entry): Generate arm eabi filter lists.
For some chips, like xstormy16 and m16c, function pointers are wider
than other pointers. These types of chips can use thunks to get
around this for gcc, but there are still a few cases when you want to
know the real (>16 bit) address of the function (reset vectors, for
example).
If you use code
On Wed, Jun 29, 2005 at 09:17:07PM -0400, Daniel Berlin wrote:
> 1. In require_complete_types_for_parms, in the C++ FE, reset DECL_SIZE
> to NULL before we call layout_decl on the parm and let layout_decl
> figure out what to do.
This is what relayout_decl does.
> 2. Add code in layout_decl to co
On 6/29/05, Russell Shaw <[EMAIL PROTECTED]> wrote:
> Alloca is like creating a stack variable, except it just gives you some
> generic bytes that don't mean anything. Exiting the local scope will
> trash the local variables and anything done with alloca(). You'll need
> to store some information i
61 matches
Mail list logo
