Hi,
I try to change the front-end tree structure of a c/c++ program as a
side effect of execution of a pragma. The operations that are involved
is to walk through in a tree (i.e "C" block), insertion of a tree
(i.e. statement, block, declaration) in the abstract syntax tree and
deletion of a tree
>From: Ulrich Weigand
>
>Erwin Unruh wrote:
>
>> I have a problem with delete_output_reload. It sometimes deletes
>> instructions which are needed. Here an analysis of a recent
>case (In a
>> private version of the S390 port). The original S390 shows
>almost the
>> same reloads, but chooses d
That idea got nixed, but I think it's time to revisit it. Paolo has
worked out the kinks in the configury and we should apply his patch and
import the gmp/mpfr sources, IMHO.
Note that these two issues (my patch, which by the way was started and
tested by Nick Clifton, and whether to import
> I try to change the front-end tree structure of a c/c++ program as a
> side effect of execution of a pragma. The operations that are involved
> is to walk through in a tree (i.e "C" block), insertion of a tree
> (i.e. statement, block, declaration) in the abstract syntax tree and
> deletion of a
Hi Revital,
Thank you very much.. This is very helpful. I was about to lost myself
in the code. I will try to experiment with your advices.
Also, having the opportunity, I would like to ask you if there is any
function to use for deleting a tree (most particularly a statement or
variable declara
Ferad Zyulkyarov writes:
>
> Also, having the opportunity, I would like to ask you if there is any
> function to use for deleting a tree (most particularly a statement or
> variable declaration tree) or it would be enough to assign it as NULL
> (which does not seems to be a gentle solution).
Erwin Unruh wrote:
> Sorry, I mislead you. Somehow I did confuse (mem/c:DI (reg:SI 2 2) [0 S8
> A8])
> with (reg:DI 2). Register 2 is used correctly.
> I do not think any reload is inherited in this case.
Ah, right. That did confuse me ;-)
> I did find something which might be the real problem.
Kaveh R. GHAZI wrote on 12/04/06 21:32:
That idea got nixed, but I think it's time to revisit it. Paolo has
worked out the kinks in the configury and we should apply his patch and
import the gmp/mpfr sources, IMHO.
Yes, I vote to include gmp/mpfr in the tree. If gmp/mpfr is still a
fluid tar
Le Tue, Dec 05, 2006 at 07:12:08AM -0500, Diego Novillo écrivait/wrote:
> Kaveh R. GHAZI wrote on 12/04/06 21:32:
> >That idea got nixed, but I think it's time to revisit it. Paolo has
> >worked out the kinks in the configury and we should apply his patch and
> >import the gmp/mpfr sources, IMHO.
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> > That idea got nixed, but I think it's time to revisit it. Paolo has
> > worked out the kinks in the configury and we should apply his patch and
> > import the gmp/mpfr sources, IMHO.
>
> Note that these two issues (my patch, which by the way was start
Hello all,
I am working on adding a new data type in gcc under C.
Please tell me, if I don't want to use the debugging info/format in
DBX, but still I want to build gcc in cygwin… what changes should be
made on dbxout.c?
Is it compulsory that I have to provide support in dbxout.c?
Thanks in adv
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> I'm not sure to follow Diego and I am a bit concerned about other
> potential external libraries. Suppose for example that some GCC code
> uses an external library like the Parma Polyedral Library
> http://www.cs.unipr.it/ppl/ (which is very usefu
"RAHUL V R" <[EMAIL PROTECTED]> writes:
> I am working on adding a new data type in gcc under C.
>
> Please tell me, if I don't want to use the debugging info/format in
> DBX, but still I want to build gcc in cygwin
what changes should be
> made on dbxout.c?
> Is it compulsory that I have to pro
> This all may just be a shakedown problem with MPFR, and maybe it will
> stabilize shortly. But it's disturbing that after one undistributed
> version became a requirement, we then very shortly stepped up to a new
> undistributed version. I think it should be obvious that if we
> require an exte
Paul Brook <[EMAIL PROTECTED]> writes:
> > This all may just be a shakedown problem with MPFR, and maybe it will
> > stabilize shortly. But it's disturbing that after one undistributed
> > version became a requirement, we then very shortly stepped up to a new
> > undistributed version. I think i
>> I did find something which might be the real problem. Within
>> delete_output_reload there are two calls to count_occurrences. The
>> second one will be called with parameters
>
>...
>
>> Due to this difference, no occurence is found. So the second
>> operand=20 of the (plus:DI ...) is not
On 05 Dec 2006 07:16:04 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Paul Brook <[EMAIL PROTECTED]> writes:
> > This all may just be a shakedown problem with MPFR, and maybe it will
> > stabilize shortly. But it's disturbing that after one undistributed
> > version became a requirement, w
Richard Guenther wrote:
>> As far as I know both versions are released. What I said was
>> "undistributed," by which I mean: the required version of MPFR is not
>> on my relatively up to date Fedora system.
>
> It also missed the openSUSE 10.2 schedule (which has the old version
> with all patch
On Dec 4, 2006, at 20:19, Howard Hinnant wrote:
If that is the question, I'm afraid your answer is not accurate.
In the example I showed the difference is 2 ulp. The difference
appears to grow with the magnitude of the argument. On my systems,
when the argument is DBL_MAX, the difference
Hello,
I have a RCM3400 Rabbitcore and I must create a client with this
circuit. I have created a C# file with Visual Studio but I need a
Dynamic C file ( or C file) to program the Rabbit. Then,I must
translate this in Dynamic C language.
How can I do?
BYE.
Naviga e telefona senza limiti c
Hi folks.
I have just merged gimple-tuples-branch into mainline.
The memory improvements as of last night are as follows:
-O0: 0.260409%
-O1: 0.828741%
-O2: 0.826724%
These are averages in analyzing about 8000 functions taken from Diego's .i
sandbox. I used the same met
Hello,
the message is off-topic here (this is a list about GCC development),
but the answer to your question is easy and short: you should write your
program in C.
Cheers,
Roberto
[EMAIL PROTECTED] wrote:
Hello,
I have a RCM3400 Rabbitcore and I must create a client with this
circuit. I ha
Snapshot gcc-4.2-20061205 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061205/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I've been investigating a testsuite failure which shows up with the new
TER implementation, and it appears to be a bug in the code for
expand_builtin_memcpy.
The problem is an array slice of a string constant, which is this case
originates in gfortran.
The source code looks like:
subroutine f
Cancel that, it's a local change of mine causing the breakage :)
On 12/5/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
Aldy, your tuples change broke teh build on i686-darwin.
I've attached a file that fails, it should fail with a cross compiler.
>
>
> I've been investigating a testsuite failure which shows up with the new
> TER implementation, and it appears to be a bug in the code for
> expand_builtin_memcpy.
>
> Does that seem reasonable? or would everyone prefer I get it fixed
> before checking in the TER code?
I would prefer you
On Dec 5, 2006, at 3:14 AM, Ferad Zyulkyarov wrote:
Also, having the opportunity, I would like to ask you if there is any
function to use for deleting a tree
ggc_free if you _know_ it is free.
On 12/5/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
My preference is to check in the TER code which exposes this bug, and
open a PR against the failure with this info. That way we don't lose
track of the problem, and someone can fix it at their leisure. Until
then there will be a testsuite fai
Hello
I am not sure to understand what if_marked or deletable means in GTY context
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html
http://gcc.gnu.org/wiki/Memory_management
I want to have a GTY() garbage collected structure such that, when it
is destoyed, some specific routine is called (t
I want to have a GTY() garbage collected structure such that, when it
is destoyed, some specific routine is called (this should indeed be
possible, since GGC is a mark& sweep garbage collector, which delet
individually each dead data).
if_marked and deletable are not what you want; they are two
Richard Guenther wrote:
It's a matter of making the cbrt builtin available - I have a patch for
this, but wondered if the fortran frontend can rely on the cbrt library call
being available? Or available in a fast variant, not a fallback
implementation in libgfortran which does pow (x, 1./3.)
Dear GCC Developers,
I want to port an existing backend (based on version gcc-2.7.2.3) on the
most recent release (gcc-4.1.1). During compilation process I get
several messages about some poisened macro definitions. The macros which
make problems are listed below:
---snip---
Toon Moene wrote:
Richard Guenther wrote:
It's a matter of making the cbrt builtin available - I have a patch
for this,
Oh, BTW, my own version of this patch (plus your work in the area of
sqrt) had the following effect on a profile breakdown (every routine
above 2 %) of the forecasting co
On 12/5/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> It's a matter of making the cbrt builtin available - I have a patch for
> this, but wondered if the fortran frontend can rely on the cbrt library call
> being available? Or available in a fast variant, not a fallback
>
I read something about poisened macros and that they shouldn't be used
anymore. But in fact I was not able to find any documentation about
these macros. When were they declared as poisened and especially why?
What should be done instead of using this macros? Just uncommenting
everything can't be
I am not sure to understand what if_marked or deletable means in GTY context
"Deletable" just sets the pointer to NULL on garbage collection, in
practice making it a weak pointer. "If_marked" provides a callback for
a bit more sophisticated weak pointers, so that an user-provided
routine can tel
On Mon, Dec 04, 2006 at 07:51:00PM +, Manuel López-Ibáñez wrote:
> Dear Janis,
> I am having problems implementing your proposal.
> The following testcase should fail with current mainline for everydg-bogus.
> It actually passes perfectly :-(. I have tried removingthe dg-warning
> tests but
On Dec 5, 2006, at 12:32 PM, Toon Moene wrote:
Couldn't libgfortran just simply borrow, errr, include the glibc
version ?
No, not without asking the FSF (rms) as I think the license is
different (GPL v GPL+libgcc exception).
Dear GCC Experts,
I am trying to understand the subtleties of __attribute__((packed)). I
have some code that works on x86, where unaligned accesses work, but
fails on ARM where they do not.
As far as I can see, if I declare a struct with the packed attribute
applied to the whole struct, lik
Toon Moene wrote:
Toon Moene wrote:
Richard Guenther wrote:
It's a matter of making the cbrt builtin available - I have a patch
for this,
Oh, BTW, my own version of this patch (plus your work in the area of
sqrt) had the following effect on a profile breakdown
The speed up is around 5
On 12/5/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Toon Moene wrote:
> Toon Moene wrote:
>
>> Richard Guenther wrote:
>>
>>> It's a matter of making the cbrt builtin available - I have a patch
>>> for this,
>
> Oh, BTW, my own version of this patch (plus your work in the area of
> sqrt) had the f
On Tuesday 05 December 2006 22:40, Phil Endecott wrote:
> Dear GCC Experts,
>
> I am trying to understand the subtleties of __attribute__((packed)). I
> have some code that works on x86, where unaligned accesses work, but
> fails on ARM where they do not.
>
> As far as I can see, if I declare a st
On 05/12/06, Janis Johnson <[EMAIL PROTECTED]> wrote:
On Mon, Dec 04, 2006 at 07:51:00PM +, Manuel López-Ibáñez wrote:
> The following testcase should fail with current mainline for everydg-bogus.
> It actually passes perfectly :-(. I have tried removingthe dg-warning
> tests but then only
On Tue, Dec 05, 2006 at 11:47:48PM +, Manuel López-Ibáñez wrote:
> On 05/12/06, Janis Johnson <[EMAIL PROTECTED]> wrote:> On Mon, Dec 04,
> 2006 at 07:51:00PM +, Manuel López-Ibáñez wrote:> > The following
> testcase should fail with current mainline for everydg-bogus.> > It
> actually p
On 12/5/06, Basile STARYNKEVITCH <[EMAIL PROTECTED]> wrote:
Hello
I am not sure to understand what if_marked or deletable means in GTY context
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html
http://gcc.gnu.org/wiki/Memory_management
I want to have a GTY() garbage collected structure such
I'm getting several thousand gfortran testsuite errors with messages
like:
FAIL: gfortran.dg/PR19754_2.f90 -O3 -fomit-frame-pointer -funroll-
all-loops -finline-functions (test for excess errors)
Excess errors:
/Users/gcc-test/programs/gcc/mainline/gcc/testsuite/gfortran.dg/
PR19754_2.f90:
On Wed, Dec 06, 2006 at 01:11:17AM -0500, Bradley Lucier wrote:
> I'm getting several thousand gfortran testsuite errors with messages
> like:
>
> FAIL: gfortran.dg/PR19754_2.f90 -O3 -fomit-frame-pointer -funroll-
> all-loops -finline-functions (test for excess errors)
> Excess errors:
> /Use
On Dec 6, 2006, at 1:33 AM, Steve Kargl wrote:
So when was the last good bootstrap?
I last bootstrapped and regtested this configuration here
http://www.math.purdue.edu/~lucier/gcc/test-results/4_3_0_2006-11-11.gz
The results appear roughly similar. (This is a recent architecture
triple.
> On Dec 6, 2006, at 1:33 AM, Steve Kargl wrote:
>
> >So when was the last good bootstrap?
>
> I last bootstrapped and regtested this configuration here
>
> http://www.math.purdue.edu/~lucier/gcc/test-results/4_3_0_2006-11-11.gz
>
> The results appear roughly similar. (This is a recent archite
On Dec 6, 2006, at 2:18 AM, Steve Kargl wrote:
On Dec 6, 2006, at 1:33 AM, Steve Kargl wrote:
So when was the last good bootstrap?
I last bootstrapped and regtested this configuration here
http://www.math.purdue.edu/~lucier/gcc/test-results/
4_3_0_2006-11-11.gz
The results appear roug
On x86, the order of prefix SEG_PREFIX, ADDR_PREFIX, DATA_PREFIX and
LOCKREP_PREFIX isn't fixed. Currently, gas generates
LOCKREP_PREFIX ADDR_PREFIX DATA_PREFIX SEG_PREFIX
I will check in a patch:
http://sourceware.org/ml/binutils/2006-12/msg00054.html
tomorrow and change gas to generate
SEG_P
51 matches
Mail list logo
