http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
This bug was originally reported against 3.4.0. It is still present in
4.3.3. Giovanni Bajo came up with a patch to fixincludes to take care of
it. Bruce Korb was supposed to apply it, but he seems to have gone AWOL.
To whoever is currently main
On Fri, 27 Feb 2009, Diego Novillo wrote:
> We will be reading IL containing both overflow and non-overflow
> operations. We should define the combination rules for them.
The rules are simple:
* No transformation (of arithmetic operations, which is what we are
discussing here) may change defin
On Thu, Feb 26, 2009 at 06:05, Richard Guenther wrote:
> There shall be no construct in the GIMPLE IL that invokes
> undefined behavior.
Excellent! Thanks for starting this branch.
> Thus, from now on integer overflow is defined and will wrap with
> the usual twos-complement semantics. Thu
Jay Foad writes:
>From an optimisation pass's point of view, what's the difference between:
>
> 1. a PLUS expression that gives an undefined result on overflow, and
> 2. a PLUS expression with a guarantee that the result won't overflow.
>
> I can't see how they will be handled any differently in
Snapshot gcc-4.4-20090227 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090227/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Hello everybody,
the idea I presented last year [1], and which I said in January that I thought
how to
realize [2], has come true.
I'd like to show you a tool that removes a bit of redundancy off your binaries,
without
needing to change the sources, by identifying repeated code blocks, and
s
On Fri, 27 Feb 2009, Jay Foad wrote:
> > To support languages that have undefined semantics on overflowing
> > operations the middle-end gets new unary and binary operators
> > that implicitly encode value-range information about their operands
> > noting that the operation does not overflow. The
On Fri, 2009-02-27 at 21:04 +0100, Rolf Ebert wrote:
> > Right, that's why the change should be reverted on the 4.3 branch. On the
> > other hand, if you can get the ZCX support to work on the mainline before
> > 4.4.0 is released, we could try there.
>
> FYI, I have just succeeded in building
On Fri, 27 Feb 2009, Sean D'Epagnier wrote:
> Hi,
>
> I just added support for printf and scanf of fixed point types to avr
> libc. I wanted to handle:
>
> Currently "accum" and "fract" work, but not "short accum" or "short fract"
>
> This is not a problem for integers currently since they g
On Fri, Feb 27, 2009 at 12:51 PM, Nils Pipenbrinck
wrote:
> Hi folks.
>
> While optimizing some of my code I replaced powf (x, 1.5f) with x * sqrt(x).
> Out of couriosity I checked if GCC does this optimization and found it in
> the code. It's in expand_builtin_pow in the file builtin.c (gcc 4.3.1
Hi,
I just added support for printf and scanf of fixed point types to avr
libc. I wanted to handle:
Currently "accum" and "fract" work, but not "short accum" or "short fract"
This is not a problem for integers currently since they get type
promoted when passed with stdarg.
There is nothing i
> FYI, I have just succeeded in building gcc-4.3.3 including Ada for MinGW
> by setting
>ZCX_By_Default: constant Boolean := True;
> in system-mingw.ads as suggested by Danny Smith. The ACATS tests show
> quite some failures, though. I don't know if they are due to the EH or
>
Hi folks.
While optimizing some of my code I replaced powf (x, 1.5f) with x *
sqrt(x). Out of couriosity I checked if GCC does this optimization and
found it in the code. It's in expand_builtin_pow in the file builtin.c
(gcc 4.3.1 source).
However, GCC does not apply this optimization for a
> It's too late for that in my mind, this feature should first be developed
> on trunk in stage 1, get proper testing, and then potentially back ported
> if it makes sense.
IMO you cannot backport such an incompatible change to a release branch. If
the Windows maintainers are confident enough wi
Right, that's why the change should be reverted on the 4.3 branch. On the
other hand, if you can get the ZCX support to work on the mainline before
4.4.0 is released, we could try there.
FYI, I have just succeeded in building gcc-4.3.3 including Ada for MinGW
by setting
ZCX_By_Default
> > Do we have time (and release-managerial leeway)? I probably couldn't
> > start sending patches until the other side of the weekend.
>
> I think we can take the (small) risk for 4.4.0; it's only the Ada compiler and
> only on Windows.
It's too late for that in my mind, this feature should f
> To support languages that have undefined semantics on overflowing
> operations the middle-end gets new unary and binary operators
> that implicitly encode value-range information about their operands
> noting that the operation does not overflow. These does-not-overflow
> operators transform the
"Rahul Kharche" writes:
> GCSE won't help with your trimmed down example
>
> int main(void)
> {
> long a = 0xcafecafe;
>
> printf("Final: %lx %lx %lx\n", a, a+5, a+15);
> return EXIT_SUCCESS;
> }
>
> I believe Paolo's canon_reg solution together with tweaking
> rtx_cost of constants wi
> Do we have time (and release-managerial leeway)? I probably couldn't
> start sending patches until the other side of the weekend.
I think we can take the (small) risk for 4.4.0; it's only the Ada compiler and
only on Windows.
> Well... I think that whatever kind of harm it could possibly
No, there is a list of wiki users considered superusers (IE able to
become other people on the wiki, remove spam, etc).
It requires no underlying permissions or accounts on sourceware itself.
On Fri, Feb 27, 2009 at 10:08 AM, Christopher Faylor
wrote:
> On Thu, Feb 26, 2009 at 04:08:03PM -0500,
Eric Botcazou wrote:
>> Ah, thanks, I'll have to research this change, I don't know about it yet.
>
> Hidden in http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00267.html
> The compiler was working before the change so just reverting it should make
> it
> work again. The change was totally accident
John Regehr writes:
> This effort is relevant:
>
> http://research.microsoft.com/en-us/um/people/jcondit/capriccio-sosp-2003.pdf
Yes. Unfortunately, their analysis which lets them avoid testing at the
entry to each function requires a complete call graph, which is not
something gcc can assume i
This effort is relevant:
http://research.microsoft.com/en-us/um/people/jcondit/capriccio-sosp-2003.pdf
John Regehr
Mathieu Lacage writes:
> On Fri, 2009-02-27 at 08:54 -0800, Ian Lance Taylor wrote:
>
>> > It would be totally awesome to do this if you could provide an option to
>> > delegate to a user-provided function the allocation and deallocation of
>> > the stack blobs needed by threads.
>>
>> Yes, this
Please do not forward this to anyone else. This offer is valid for the
recipient only.
You have been selected to try our new games.
Get £20 and walk away with your returns.
Click here to play! www.temptative.com/go
Kind regards,
Tempative Offers
www.temptative.com/go
On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
> Hi,
>
> > > introducing new codes seems like a bad idea to me. There are many
> > > places that do not care about the distinction between PLUS_EXPR and
> > > PLUSV_EXPR, and handling both cases will complicate the code (see eg.
> > > the problems cause
On Fri, 2009-02-27 at 08:54 -0800, Ian Lance Taylor wrote:
> > It would be totally awesome to do this if you could provide an option to
> > delegate to a user-provided function the allocation and deallocation of
> > the stack blobs needed by threads.
>
> Yes, this would be a goal.
The main reaso
Hi,
> > I obviously thought about this. The issue with using a flag is
> > that there is no convenient place to stick it and that it makes
> > the distinction between the two variants less visible. Consider
> > the folding routines that take split trees for a start.
> >
> > IMHO using new tree-
Hi,
> > introducing new codes seems like a bad idea to me. There are many
> > places that do not care about the distinction between PLUS_EXPR and
> > PLUSV_EXPR, and handling both cases will complicate the code (see eg.
> > the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR
> > dis
> Ah, thanks, I'll have to research this change, I don't know about it yet.
Hidden in http://gcc.gnu.org/ml/gcc-cvs/2007-12/msg00267.html
> I'm not sure if I'll find time to investigate reverting it on the branch:
> my priorities are focussed around maintaining the Cygwin distro compiler
> and
Mathieu Lacage writes:
> On Thu, 2009-02-26 at 14:05 -0800, Ian Lance Taylor wrote:
>> I've put a project proposal for split stacks on the wiki at
>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
>> of a single thread to be split into discontiguous segments, thus
>> permi
Andi Kleen writes:
> Ian Lance Taylor writes:
>
>> I've put a project proposal for split stacks on the wiki at
>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
>> of a single thread to be split into discontiguous segments, thus
>> permitting many more threads to be activ
Paul Brook wrote:
> ARM unwind tables are series of open ranges (only the start address is
> specified for each region). i.e. your assumption that the search will fail is
> incorrect. It will actually find the entry for the preceding function.
> The new linker bits automatically add cantunwind e
Eric Botcazou wrote:
>> Hello all, and ADA hackers in particular :-)
>
> Ada, not ADA, that's not an acronym but a name, see http://www.adaic.org
Yes, of course, I knew that really. My most humble apologies to the
late Ms. Lovelace :-)
>> The first problem I ran into was total failure
Sure, I moved my project suggestions to "other projects" section
and added contact info ...
Cheers,
Grigori
> -Original Message-
> From: Manuel López-Ibáñez [mailto:lopeziba...@gmail.com]
> Sent: Thursday, February 26, 2009 8:41 PM
> To: Grigori Fursin
> Cc: Sebastian Pop; gcc@gcc.gnu.or
Sure, Diego!
By the way, we just finished preparing the small patch for the high-level
plugin API
(that includes pass manipulation and parameter tuning) synchronized with the
current
plugin branch (on top of Le-Chun's patch) and should be able to send it tonight
...
Cheers,
Grigori
> -Ori
On Friday 27 February 2009, Dave Korn wrote:
> Julian Brown wrote:
> > Unfortunately backtraces don't currently terminate cleanly if code
> > without unwind data is reached: CodeSourcery are currently working on
> > fixing the linker so that non-unwindable regions are marked properly,
> > which we
Dave Korn wrote:
> Julian Brown wrote:
>
>> Unfortunately backtraces don't currently terminate cleanly if code
>> without unwind data is reached: CodeSourcery are currently working on
>> fixing the linker so that non-unwindable regions are marked properly,
>> which we consider essential to making
Julian Brown wrote:
> Unfortunately backtraces don't currently terminate cleanly if code
> without unwind data is reached: CodeSourcery are currently working on
> fixing the linker so that non-unwindable regions are marked properly,
> which we consider essential to making this feature usable.
I
Dear Vladimir,
> Not really. There is no requirement for "the units
> part of the alternatives of a reservation must belong to the
> same automaton". Querying should also work in this
> case because function cpu_unit_reservation_p checks all
> automata for an unit reservation.
Indeed it che
On Thu, Feb 26, 2009 at 05:57, Grigori Fursin wrote:
> I am fine to mentor a few of them (particularly from 1-3) but would like to
> see if someone
> is interested to help with that ?.. I added these topics to the GCC GSOC page:
> http://gcc.gnu.org/wiki/SummerOfCode
> and would be happy if you
On Thu, 26 Feb 2009, Vincent Lefevre wrote:
> After a buffer overflow has been found (and fixed) in the
> mpfr_snprintf and mpfr_vsnprintf functions of MPFR 2.4.0,
> it has been decided to release MPFR 2.4.1 immediately.
> It is available for download from the MPFR web site:
>
> http://www.mpfr.
> Hello all, and ADA hackers in particular :-)
Ada, not ADA, that's not an acronym but a name, see http://www.adaic.org
> However the main issues I've been having trouble with show up when I try
> and run the testsuite.
>
> The first problem I ran into was total failure to throw and catch
On Thu, Feb 26, 2009 at 04:08:03PM -0500, Daniel Berlin wrote:
>If you want to help admin the wiki, I am more than happy to make you a
>super user.
>That goes for Steven, etc.
Wait. Are we talking about giving people root access on sourceware
just to clean up a wiki? Hopefully this is not the ca
Julian Brown wrote:
> On Thu, 26 Feb 2009 15:54:14 +
> Andrew Haley wrote:
>
>> Paul Brook wrote:
Well, but wouldn't it still be nice if
__builtin_return_address(N) was implemented for N>0 by libcalling
into the unwinder for you? Obviously this would still have to
retur
On Fri, 27 Feb 2009 13:32:11 +
Julian Brown wrote:
> GLIBC already knows how to do backtracing if the ARM-specific unwind
> tables are present (.ARM.exidx, etc.), using _Unwind_Backtrace.
I'm told this probably isn't true for upstream GLIBC -- but we
definitely have a patch somewhere to make
On Fri, Feb 27, 2009 at 09:10:10AM +0100, Mathieu Lacage wrote:
> - if you want to use the stack protector and split stacks, it should
> be fairly trivial to extend the data structure which contains the stack
> protector with a new field, no ?
The stack protector is just a word, not a pointer.
2009/2/27 Dave Korn :
> daniel tian wrote:
>
>> That seems to solving a address mode problem. My problem is that while
>> loading a large immediate data or SYMBOL_REF, the destination is a
>> specified general register (register 0:R0). So I don't how to let the
>> define_expand "movsi" pattern to
On Fri, 27 Feb 2009, Dave Korn wrote:
> Richard Guenther wrote:
>
> > It's definitely safer. Still we have to carefully modify existing
> > code to deal with the new tree codes as most of it carelessly
> > transitiones old codes to new trees. For example re-associating
> > (a +/nv b) + c to a +
Richard Guenther wrote:
> It's definitely safer. Still we have to carefully modify existing
> code to deal with the new tree codes as most of it carelessly
> transitiones old codes to new trees. For example re-associating
> (a +/nv b) + c to a +/nv (b + c) is wrong.
Yes, of course we have to
On Thu, 26 Feb 2009 15:54:14 +
Andrew Haley wrote:
> Paul Brook wrote:
> >> Well, but wouldn't it still be nice if
> >> __builtin_return_address(N) was implemented for N>0 by libcalling
> >> into the unwinder for you? Obviously this would still have to
> >> return NULL at runtime when you'
Hello all, and ADA hackers in particular :-)
I've been having a hard time bootstrapping GNAT 4.3.2 lately, and now I
think I've found the problem. Or /a/ problem, but I'm not sure exactly why
it's a problem in the first place. Let me explain:
As mentioned in an earlier thread, you can
On Fri, 27 Feb 2009, Dave Korn wrote:
> Richard Guenther wrote:
> > On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
>
> >> introducing new codes seems like a bad idea to me. There are many
> >> places that do not care about the distinction between PLUS_EXPR and
> >> PLUSV_EXPR, and handling both cases
Richard Guenther wrote:
> On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
>> introducing new codes seems like a bad idea to me. There are many
>> places that do not care about the distinction between PLUS_EXPR and
>> PLUSV_EXPR, and handling both cases will complicate the code (see eg.
>> the problems
Mathieu Lacage wrote:
> It would be totally awesome to do this if you could provide an option to
> delegate to a user-provided function the allocation and deallocation of
> the stack blobs needed by threads.
> Ideally, I would even be able to use heap memory for that stack space if
> I wanted to.
daniel tian wrote:
> That seems to solving a address mode problem. My problem is that while
> loading a large immediate data or SYMBOL_REF, the destination is a
> specified general register (register 0:R0). So I don't how to let the
> define_expand "movsi" pattern to generate destination register
> - If I patch in this code, actually I get the same results I did
> before where the constants are propagated. It seems that in 4.3.2,
> every part of the compiler is trying to do that.
There are at least two forward propagation passes, one before and
another after GCSE. I haven't tried to tackle
On Fri, 27 Feb 2009, Zdenek Dvorak wrote:
> Hi,
>
> in general, I like this proposal a lot. However,
>
> > As a start there will be no-overflow variants of NEGATE_EXPR,
> > PLUS_EXPR, MINUS_EXPR, MULT_EXPR and POINTER_PLUS_EXPR.
> >
> > The sizetypes will simply be operated on in no-overflow v
Ian Lance Taylor wrote:
> Joel Sherrill writes:
>
>> Ian Lance Taylor wrote:
>>> I've put a project proposal for split stacks on the wiki at
>>> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
>>> of a single thread to be split into discontiguous segments, thus
>>> permitti
Please go ahead. I do not have much time for gcc lately but I will be
more than happy to clean up whatever spam I find in the wiki or ban
spammers.
Cheers,
Manuel.
2009/2/26 Daniel Berlin :
> If you want to help admin the wiki, I am more than happy to make you a
> super user.
> That goes for Ste
2009/2/27 Joern Rennecke :
> Quoting daniel tian :
>
>> 2009/2/26 Joern Rennecke :
the address label "common_reg " used many times. I think it will
load one time. But after optimized with '-Os' or '-O2', it still loads
the label "common_reg " six times..
>>>
>>> Previously, you
comments below,
On Thu, 2009-02-26 at 14:05 -0800, Ian Lance Taylor wrote:
> I've put a project proposal for split stacks on the wiki at
> http://gcc.gnu.org/wiki/SplitStacks . The idea is to permit the stack
> of a single thread to be split into discontiguous segments, thus
> permitting many mor
62 matches
Mail list logo
