Re: Information about LTO
On 5/2/07, Sjodin, Jan <[EMAIL PROTECTED]> wrote: Thanks for all the responses. It seems like LTO will have to wait for the tuples or there will be a lot of throw-away code. If you really only can think of LTO as the reader/writer, then perhaps yes. But if you read back this thread, you would have seen a bunch of suggestions for how you can help with LTO prerequisites that do not depend on tuples at all. You should look at the bigger picture. Gr. Steven
bugzilla broken?
Hi, for reasons I don't know, I am not able to create attachments in gcc's bugzilla for ca the last 24hrs. When doing so, I am greeted with the message below. --- snip --- Internal Error GCC Bugzilla has suffered an internal error. Please save this page and send it to [EMAIL PROTECTED] with details of what you were doing at the time this message appeared. URL: http://gcc.gnu.org/bugzilla/attachment.cgi undef error - Undefined subroutine Fh::slice at data/template/template/en/default/global/hidden-fields.html.tmpl line 58 --- snip --- dberlin has been mailed, but no reaction so far. Ralf
RE: bugzilla broken?
On 03 May 2007 08:52, Ralf Corsepius wrote: > Hi, > > for reasons I don't know, I am not able to create attachments in gcc's > bugzilla for ca the last 24hrs. When doing so, I am greeted with the > message below. > > --- snip --- > Internal Error > > GCC Bugzilla has suffered an internal error. Please save this page and > send it to [EMAIL PROTECTED] with details of what you were doing at > the time this message appeared. > > URL: http://gcc.gnu.org/bugzilla/attachment.cgi > > undef error - Undefined subroutine Fh::slice at > data/template/template/en/default/global/hidden-fields.html.tmpl line > 58 > --- snip --- > dberlin has been mailed, but no reaction so far. Clear your cookie and try again. cheers, DaveK -- Can't think of a witty .sigline today
RE: bugzilla broken?
On Thu, 2007-05-03 at 10:36 +0100, Dave Korn wrote: > On 03 May 2007 08:52, Ralf Corsepius wrote: > > > Hi, > > > > for reasons I don't know, I am not able to create attachments in gcc's > > bugzilla for ca the last 24hrs. When doing so, I am greeted with the > > message below. > > > > --- snip --- > > Internal Error > > > > GCC Bugzilla has suffered an internal error. Please save this page and > > send it to [EMAIL PROTECTED] with details of what you were doing at > > the time this message appeared. > > > > URL: http://gcc.gnu.org/bugzilla/attachment.cgi > > > > undef error - Undefined subroutine Fh::slice at > > data/template/template/en/default/global/hidden-fields.html.tmpl line > > 58 > > --- snip --- > > dberlin has been mailed, but no reaction so far. > > > Clear your cookie and try again. Thanks, this helped. Ralf
Re: bugzilla broken?
On 5/3/07, Ralf Corsepius <[EMAIL PROTECTED]> wrote: Hi, for reasons I don't know, I am not able to create attachments in gcc's bugzilla for ca the last 24hrs. When doing so, I am greeted with the message below. --- snip --- Internal Error GCC Bugzilla has suffered an internal error. Please save this page and send it to [EMAIL PROTECTED] with details of what you were doing at the time this message appeared. URL: http://gcc.gnu.org/bugzilla/attachment.cgi undef error - Undefined subroutine Fh::slice at data/template/template/en/default/global/hidden-fields.html.tmpl line 58 --- snip --- Sadly, I can't make a better error message here without a bunch of supporting code that got later added in bugzilla. What is actually happening is that you aren't logged in when you try to submit the attachment. Bugzilla says "okay, i'll just save all the data they entered in a hidden field and ask them to log in". For various reasons, it can't save the attachment data in a hidden field. You log in it then tries to find the attachment data it couldn't save, and issues this error message. The solution is simply to log in before you submit attachments. I'm happy to put this in huge letters somewhere, just tell me where. In later bugzilla's, the error message is now nicer, and includes a place to reattach the file easily. This requires a bunch of support code our bugzilla version does not have. I am simply waiting for bugzilla 3.0 to release, so i can remove most of our bugzilla hacks in favor of the now-support ways of doing things like custom fields. dberlin has been mailed, but no reaction so far. I was off fixing my Nintendo Wii, so i wasn't checking email :)
Re: __ffssi2 not exported in libgcc_s.so
Andreas Krebbel <[EMAIL PROTECTED]> writes: > What I'm curious about is why this didn't occur earlier?! The symbol > is available since 2003 and I can hardly imagine that no platform was > ever in need of it till now. To answer that, I'm afraid my patch is to blame: 2007-04-24 Richard Sandiford <[EMAIL PROTECTED]> * optabs.c (set_conv_libfunc): Prefer libgcc2's __ffsMM2 functions over an external ffs function. We used to use ffs to implement __builtin_ffs if sizeof (int), even if libgcc provided a suitable alternative. This broke targets whose C libraries don't provide their own ffs. __ffssi2 was effectively dead code on many targets until now. Richard
Re: bugzilla broken?
On Thu, 2007-05-03 at 07:01 -0400, Daniel Berlin wrote: > On 5/3/07, Ralf Corsepius <[EMAIL PROTECTED]> wrote: > > Hi, > > > > for reasons I don't know, I am not able to create attachments in gcc's > > bugzilla for ca the last 24hrs. When doing so, I am greeted with the > > message below. > > > > --- snip --- > > Internal Error > > > > GCC Bugzilla has suffered an internal error. Please save this page and > > send it to [EMAIL PROTECTED] with details of what you were doing at > > the time this message appeared. > > > > URL: http://gcc.gnu.org/bugzilla/attachment.cgi > > > > undef error - Undefined subroutine Fh::slice at > > data/template/template/en/default/global/hidden-fields.html.tmpl line > > 58 > > --- snip --- > > Sadly, I can't make a better error message here without a bunch of > supporting code that got later added in bugzilla. > > What is actually happening is that you aren't logged in when you try > to submit the attachment. What actually has happened is: 1. I submitted a PR, and was asked to login several times inbetween. 2. Later I returned to "PR XXX", pressed "Create attachment" and ... first was asked to login, then created the attachment. When having finished to fill out the form, I pressed "submit" ... and wasn't asked for a password, instead had been greeted with the error message. No obvious indication of a broken/outdated cookie, no indication of a missing log-in (I even requested a new password in-between ;) ) >> dberlin has been mailed, but no reaction so far. > >I was off fixing my Nintendo Wii, so i wasn't checking email :) Well, we all are AFK from time to time - That's why I gradually was increasing the "visibility" of complaining. Ralf
GCC 4.1: Problem with old-loop and REG_EQUAL notes
Hi,
I'm debugging a problem with the GCC 4.1 old loop optimizer.
Consider the following example:
After gcse1 a loop body contains the following two insns. Note that gcse
has already replaced r974 with r1218 in insn 1743 and has attached a REG_EQUAL
note. Insn 2308 stays as a dead store - maybe thats what confuses the loop
optimizer.
(insn 2308 1740 1743 111 (set (reg/f:DI 974)
(const:DI (unspec:DI [
(symbol_ref:DI ("local") )
] 110))) 49 {*movdi_larl} (nil)
(expr_list:REG_EQUAL (const:DI (unspec:DI [
(symbol_ref:DI ("local") )
] 110))
(nil)))
(insn 1743 2308 1744 111 (set (reg/f:DI 973)
(mem/u/c:DI (reg/f:DI 1218) [0 S8 A8])) 51 {*movdi_64} (nil)
(expr_list:REG_EQUAL (mem/u/c:DI (reg/f:DI 974) [0 S8 A8])
(nil)))
The old-loop output shows that only insn 1743 was moved to the
loop preheader:
Insn 2308: regno 974 (life 0), move-insn savings 1 not desirable
Insn 1743: regno 973 (life 19), savings 1 moved to 2395
Unfortunately the REG_EQUAL note of insn 1743 is NOT deleted since
the value of r974 is loop invariant.
The loop optmizer decided to load the src of insn 1743 into a new pseudo
(the insert_temp flag is set) resulting in:
(insn 2395 2394 2397 108 (set (reg:DI 1229)
(mem/u/c:DI (reg/f:DI 1218) [0 S8 A8])) -1 (nil)
(expr_list:REG_EQUAL (mem/u/c:DI (reg/f:DI 974) [0 S8 A8])
(nil)))
before loop start and insn 2308 still in the loop body:
(insn 2308 1740 2396 110 (set (reg/f:DI 974)
(const:DI (unspec:DI [
(symbol_ref:DI ("local") )
] 110))) -1 (nil)
(expr_list:REG_EQUAL (const:DI (unspec:DI [
(symbol_ref:DI ("local") )
] 110))
(nil)))
The REG_EQUAL note is then used by cse to create an uninitialized memory access.
I don't see a fix other than removing *ALL* REG_EQUAL notes when hoisting
insns from the loop body. Would that be ok or too pessimistic?
Bye,
-Andreas-
Re: __ffssi2 not exported in libgcc_s.so
> To answer that, I'm afraid my patch is to blame: > > 2007-04-24 Richard Sandiford <[EMAIL PROTECTED]> > > * optabs.c (set_conv_libfunc): Prefer libgcc2's __ffsMM2 functions > over an external ffs function. > > We used to use ffs to implement __builtin_ffs if sizeof (int), > even if libgcc provided a suitable alternative. This broke targets > whose C libraries don't provide their own ffs. > > __ffssi2 was effectively dead code on many targets until now. Thanks for the info. So it should be safe to add it as GCC_4.3.0 only symbol. Bye, -Andreas-
Re: Effects of newly introduced -mpcX 80387 precision flag
Bradley Lucier wrote: I just (re-)discovered these tables giving maximum known errors in some libm functions when extended precision is enabled: http://people.inf.ethz.ch/gonnet/FPAccuracy/linux/summary.html and when the precision of the mantissa is set to 53 bits (double precision): http://people.inf.ethz.ch/gonnet/FPAccuracy/linux64/summary.html This is from 2002, and indeed, some of the errors in double-precision results are hundreds or thousands of times bigger when the precision is set to 53 bits. I think the warning in the documentation is very mild considering the possible effects. Perhaps the manual should also mention that sometimes this option brings a 2% improvement in the speed of FP-intensive code along with massive increases in the error of some libm functions, and then people could decide if they want to use it. (I'm not opposed to a switch like this, my favorite development environment sets the precision to 53 bits globally just as this switch does, but I think the documentation should be more clear about the trade-offs.) Could you please post a patch with suggested wording about this option (I was trying to write something similar to the warning that icc has in its documentation about precision settings). Thanks, Uros.
Re: bugzilla broken?
Ralf Corsepius wrote: 1. I submitted a PR, and was asked to login several times inbetween. I have found that clearing the browser's cookie cache for the site will often correct this problem. 2. Later I returned to "PR XXX", pressed "Create attachment" and ... first was asked to login, then created the attachment. When having finished to fill out the form, I pressed "submit" ... and wasn't asked for a password, instead had been greeted with the error message. No obvious indication of a broken/outdated cookie, no indication of a missing log-in (I even requested a new password in-between ;) ) I don't know what indication you were looking for or expecting. Acknowledged that it would be nice if it didn't break. David Daney
Re: bugzilla broken?
David Daney wrote: Ralf Corsepius wrote: 1. I submitted a PR, and was asked to login several times inbetween. I have found that clearing the browser's cookie cache for the site will often correct this problem. I should have read the rest of the thread :(. It looks like this was already suggested, and seems to have corrected the problem. David Daney
Re: bugzilla broken?
On 5/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: > dberlin has been mailed, but no reaction so far. > I was off fixing my Nintendo Wii, so i wasn't checking email :) Wait, it needed to fixed already, you should have got a PS3. -- Andrew
RE: bugzilla broken?
On 03 May 2007 16:59, Andrew Pinski wrote: > On 5/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: >>> dberlin has been mailed, but no reaction so far. >>> >> I was off fixing my Nintendo Wii, so i wasn't checking email :) > > Wait, it needed to fixed already, you should have got a PS3. > > -- Andrew I believe "fixing my wii" is a euphemism cheers, DaveK -- Can't think of a witty .sigline today
Re: bugzilla broken?
On Thu, 2007-05-03 at 08:54 -0700, David Daney wrote: > Ralf Corsepius wrote: > > > 1. I submitted a PR, and was asked to login several times inbetween. > > > > I have found that clearing the browser's cookie cache for the site will > often correct this problem. I've never had this problem before, ever since I am working with GCC, ... and that's a really long time ... ;) > > 2. Later I returned to "PR XXX", pressed "Create attachment" and ... > > first was asked to login, then created the attachment. > > When having finished to fill out the form, I pressed "submit" ... > > and wasn't asked for a password, instead had been greeted with the error > > message. > > > > No obvious indication of a broken/outdated cookie, no indication of a > > missing log-in (I even requested a new password in-between ;) ) > > > > I don't know what indication you were looking for or expecting. > Acknowledged that it would be nice if it didn't break. Sorry, I am heavily using other bugzillas too (e.g. redhat's), and never had this issue before ... Ralf
RE: bugzilla broken?
On 03 May 2007 17:04, Ralf Corsepius wrote: > On Thu, 2007-05-03 at 08:54 -0700, David Daney wrote: >> Ralf Corsepius wrote: >> >>> 1. I submitted a PR, and was asked to login several times inbetween. >>> >> >> I have found that clearing the browser's cookie cache for the site will >> often correct this problem. > I've never had this problem before, ever since I am working with > GCC, ... and that's a really long time ... ;) Other people have seen it: http://www.google.co.uk/search?hl=en&client=firefox-a&rls=org.mozilla%3Aen-GB% 3Aofficial&hs=rHy&q=data%2Ftemplate%2Ftemplate%2Fen%2Fdefault%2Fglobal%2Fhidde n-fields.html.tmpl&btnG=Search&meta= (or http://tinyurl.com/2n825k) It seems to be some kind of glitch or intermittent bug. It is fortunately quite trivial to work around. cheers, DaveK -- Can't think of a witty .sigline today
RE: Information about LTO
I agree. Also, the LTO requirements and high-level design document states that the external format should be "compiler-independent" and it should be possible for other tools to read and write that format. Is this still a goal? It would require a separate design with a distinct API to read and write code. This work could be done in parallel. The document mentions a GNU Virtual Machine. Would that be abandoned for a tuple-like external representation? Jan > -Original Message- > From: Steven Bosscher [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 03, 2007 2:39 AM > To: Sjodin, Jan > Cc: Diego Novillo; Joseph S. Myers; Ian Lance Taylor; gcc@gcc.gnu.org > Subject: Re: Information about LTO > > On 5/2/07, Sjodin, Jan <[EMAIL PROTECTED]> wrote: > > Thanks for all the responses. It seems like LTO will have to wait for > > the tuples or there will be a lot of throw-away code. > > If you really only can think of LTO as the reader/writer, then perhaps > yes. But if you read back this thread, you would have seen a bunch of > suggestions for how you can help with LTO prerequisites that do not > depend on tuples at all. You should look at the bigger picture. > > Gr. > Steven >
Re: Information about LTO
> On 5/2/07, Sjodin, Jan <[EMAIL PROTECTED]> wrote: > >Thanks for all the responses. It seems like LTO will have to wait for > >the tuples or there will be a lot of throw-away code. > > If you really only can think of LTO as the reader/writer, then perhaps > yes. But if you read back this thread, you would have seen a bunch of > suggestions for how you can help with LTO prerequisites that do not > depend on tuples at all. You should look at the bigger picture. Even concerning the reader/writer there is alot of parallelizm - writting nested gimple is just slightly different from tuples and we still need to learn how to deal with the rest of infrastructure (types, declarations, add on datastructures, APIs). We also do have LTO for Java, getting our memory consumption down to level so -funit-at-a-time is practically useful for large Java applications would make C/C++ LTO work too once writer/reader is at the place. The memory consumption is quite evenly distributed across varioius datastructures - it is definitly not like tuples will solve the problem alone - it is going to make about 13-18% of overall footprint of parsed program. Cleanups and simplifications of other datastructures are easilly done in parallel and bring immediate benefits. Honza > > Gr. > Steven
Re: Effects of newly introduced -mpcX 80387 precision flag
On May 3, 2007, at 11:11 AM, Uros Bizjak wrote:
Could you please post a patch with suggested wording about this
option (I was trying to write something similar to the warning that
icc has in its documentation about precision settings).
How about this? It perhaps reflects my own biases, but the term
"catastrophic loss of accuracy" is sometimes used in the technical
sense that I mean here. For the performance figures, I used the
figures you gave in your e-mail but add "or more" to be on the safe
side.
Brad
[descartes:~/Desktop] lucier% rcsdiff -u invoke.texi
===
RCS file: RCS/invoke.texi,v
retrieving revision 1.1
diff -u -r1.1 invoke.texi
--- invoke.texi 2007/05/03 15:43:01 1.1
+++ invoke.texi 2007/05/03 17:15:24
@@ -10139,12 +10139,21 @@
@opindex mpc80
Set 80387 floating-point precision to 32, 64 or 80 bits. When @option
{-mpc32}
-is specified, the significand of floating-point operations is
rounded to 24
-bits (single precision), @option{-mpc64} rounds the significand of
-floating-point operations to 53 bits (double precision) and @option{-
mpc80}
-rounds the significand of floating-point operations to 64 bits
(extended
-double precision). Note that a change of default precision control may
-affect the results returned by some of the mathematical functions.
+is specified, the significands of results of floating-point
operations are
+rounded to 24 bits (single precision); @option{-mpc64} rounds the the
+significands of results of floating-point operations to 53 bits (double
+precision) and @option{-mpc80} rounds the significands of results of
+floating-point operations to 64 bits (extended double precision),
which is
+the default. When this option is used, floating-point operations in
higher
+precisions are not available to the programmer without setting the FPU
+control word explicitly.
+
+Setting the rounding of floating-point operations to less than the
default
+80 bits can speed some programs by 2% or more. Note that some
mathematical
+libraries assume that extended precision (80 bit) floating-point
operations
+are enabled by default; routines in such libraries could suffer
catastrophic
+loss of accuracy when this option is used to set the precision to
less than
+extended precision.
@item -mstackrealign
@opindex mstackrealign
Re: gcov in cross-compile: have a patch, seek direction
On Tue, 2007-05-01 at 09:27 +1000, Ben Elliston wrote: > On Mon, 2007-04-23 at 22:16 +0200, Danny Backx wrote: > > > Gcov normally puts the files where it writes profiling information in > > the source directory. In a cross-development environment, that directory > > isn't always available. > > So I discovered when debugging testsuite failures on a remote target :-) > > > Gcc has support for overriding that directory at runtime. > > Unfortunately, on Windows CE, that is not always easy. > > Why, is there no concept of environment variables for Windows CE > processes? What is the real problem? For all I know there's just the registry. > > I've patched my copy of gcc to be able to specify a different directory > > at compile-time (instead of at run time). > > > > I can cleanup and submit my patch if there's interest. > > > > Prior to that, I have a question : should this support be steered via > > parameters on the compiler command line, or from environment values ? > > Don't use environment variables at compile time. It makes reproducing > problems in the field extremely difficult. We need useers to be able to > send source input plus a command line without having to further guess > their environment. Ok, a command line option is what I have. I'll try to clean up my patch shortly, and see if it still applies cleanly in a recent gcc tree. Our current version is based on gcc-4.1.0. Or is a patch against that ok ? Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info signature.asc Description: This is a digitally signed message part
Re: Effects of newly introduced -mpcX 80387 precision flag
Bradley Lucier wrote: On May 3, 2007, at 11:11 AM, Uros Bizjak wrote: Could you please post a patch with suggested wording about this option (I was trying to write something similar to the warning that icc has in its documentation about precision settings). How about this? It perhaps reflects my own biases, but the term "catastrophic loss of accuracy" is sometimes used in the technical sense that I mean here. For the performance figures, I used the figures you gave in your e-mail but add "or more" to be on the safe side. What about "significant loss of accuracy" as these options probably won't cause a nuclear reactor meltdown ;) Uros.
Re: Effects of newly introduced -mpcX 80387 precision flag
On May 3, 2007, at 2:45 PM, Uros Bizjak wrote: Bradley Lucier wrote: On May 3, 2007, at 11:11 AM, Uros Bizjak wrote: Could you please post a patch with suggested wording about this option (I was trying to write something similar to the warning that icc has in its documentation about precision settings). How about this? It perhaps reflects my own biases, but the term "catastrophic loss of accuracy" is sometimes used in the technical sense that I mean here. For the performance figures, I used the figures you gave in your e-mail but add "or more" to be on the safe side. What about "significant loss of accuracy" as these options probably won't cause a nuclear reactor meltdown ;) Well, I did some googling, and the technical term I was thinking of was "catastrophic cancellation". So how about Note that some mathematical routines in such libraries could suffer significant loss of accuracy, typically through so-called "catastrophic cancellation", when this option is used to set the precision to less than extended precision. Brad
Re: bugzilla broken?
On 5/3/07, Dave Korn <[EMAIL PROTECTED]> wrote: On 03 May 2007 16:59, Andrew Pinski wrote: > On 5/3/07, Daniel Berlin <[EMAIL PROTECTED]> wrote: >>> dberlin has been mailed, but no reaction so far. >>> >> I was off fixing my Nintendo Wii, so i wasn't checking email :) > > Wait, it needed to fixed already, you should have got a PS3. > > -- Andrew I believe "fixing my wii" is a euphemism Sadly not, it's 20 days out of warranty.
Re: Effects of newly introduced -mpcX 80387 precision flag
Bradley Lucier wrote: What about "significant loss of accuracy" as these options probably won't cause a nuclear reactor meltdown ;) Well, I did some googling, and the technical term I was thinking of was "catastrophic cancellation". So how about Note that some mathematical routines in such libraries could suffer significant loss of accuracy, typically through so-called "catastrophic cancellation", when this option is used to set the precision to less than extended precision. I think this is OK. So if nobody objects, this patch is OK for mainline. Thanks, Uros.
Re: GCC 4.1: Problem with old-loop and REG_EQUAL notes
> After gcse1 a loop body contains the following two insns. Note that gcse
> has already replaced r974 with r1218 in insn 1743 and has attached a
> REG_EQUAL note. Insn 2308 stays as a dead store - maybe thats what confuses
> the loop optimizer.
>
> (insn 2308 1740 1743 111 (set (reg/f:DI 974)
> (const:DI (unspec:DI [
> (symbol_ref:DI ("local") local>) ] 110))) 49 {*movdi_larl} (nil)
> (expr_list:REG_EQUAL (const:DI (unspec:DI [
> (symbol_ref:DI ("local") local>) ] 110))
> (nil)))
>
> (insn 1743 2308 1744 111 (set (reg/f:DI 973)
> (mem/u/c:DI (reg/f:DI 1218) [0 S8 A8])) 51 {*movdi_64} (nil)
> (expr_list:REG_EQUAL (mem/u/c:DI (reg/f:DI 974) [0 S8 A8])
> (nil)))
The note doesn't look particularly helpful in this case, given that gcse
has replaced r974 with r1218 in the insn. How is it created?
> The loop optmizer decided to load the src of insn 1743 into a new pseudo
> (the insert_temp flag is set) resulting in:
>
> (insn 2395 2394 2397 108 (set (reg:DI 1229)
> (mem/u/c:DI (reg/f:DI 1218) [0 S8 A8])) -1 (nil)
> (expr_list:REG_EQUAL (mem/u/c:DI (reg/f:DI 974) [0 S8 A8])
> (nil)))
>
> before loop start and insn 2308 still in the loop body:
>
> (insn 2308 1740 2396 110 (set (reg/f:DI 974)
> (const:DI (unspec:DI [
> (symbol_ref:DI ("local") local>) ] 110))) -1 (nil)
> (expr_list:REG_EQUAL (const:DI (unspec:DI [
> (symbol_ref:DI ("local") local>) ] 110))
> (nil)))
Is (reg/f:DI 974) loop invariant or only conditionally invariant?
--
Eric Botcazou
Expression with 2 operations
Dear all,
I must calculate the address of an element's array.
If the size of an element is one integer it's good.
I do like that:
new_rhs=fold_build2(PLUS_EXPR,TREE_TYPE(TREE_OPERAND(rhs,1)),
build1(ADDR_EXPR, build_pointer_type (TREE_TYPE
(array)),array),
index);
But, if the type of an element is not one integer, I must multiply the
index by the size of an element.
I try to do like that :
tree decalage=fold_build2(MULT_EXPR,TREE_TYPE(index),
index,
compteur);
new_rhs=fold_build2(PLUS_EXPR,TREE_TYPE(TREE_OPERAND(rhs,1)),
build1(ADDR_EXPR,
build_pointer_type (TREE_TYPE (array)),array),
decalage);
new_rhs is a futur parameter of a function call.
When a try to compile a program gcc answer:
"
tab.c:22: erreur: invalid operand to binary operator
i_28 * 4;
tab.c:22: erreur interne du compilateur: verify_stmts failed
"
i_28 is index
4 is compteur
How can I do that ?
Thanks in advance.
Antoine
This is the debug_tree() of new_rhs :
unit size
align 32 symtab 0 alias set 3 canonical type 0x403532d8
precision 32 min max 0x40342318 2147483647>
pointer_to_this >
arg 0
arg 0
visited var def_stmt 0x403e79a0>
version 28>
arg 1 >
arg 1
unsigned SI size unit size
align 32 symtab 0 alias set -1 canonical type 0x403e38f0>
constant invariant
arg 0
addressable used public static common BLK file tab.c line 7
size
unit size
align 256
(mem/s/c:BLK (symbol_ref:SI ("") >) [2 +0 S40 A256]) chain >>>
Re: Effects of newly introduced -mpcX 80387 precision flag
On May 3, 2007, at 3:29 PM, Uros Bizjak wrote: Bradley Lucier wrote: What about "significant loss of accuracy" as these options probably won't cause a nuclear reactor meltdown ;) Well, I did some googling, and the technical term I was thinking of was "catastrophic cancellation". So how about Note that some mathematical routines in such libraries could suffer significant loss of accuracy, typically through so-called "catastrophic cancellation", when this option is used to set the precision to less than extended precision. I think this is OK. So if nobody objects, this patch is OK for mainline. I'm sorry, but I don't have checkin privileges. Brad
Re: GCC 4.2.0 RC3 Available
Mark Mitchell wrote: GCC 4.2.0 RC3 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501 This build now contains the fixes for the Ada build problem present in RC2. At this point, I have no plans for an RC4. However, I am reviewing the various open issues, and available patches, so I might change my mind about that. Please see: http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html for information about reporting problems. Please see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31807 A bootstrap failure from the RC3 tarball on mipsel-unknown-linux-gnu David Daney
Re: Successfull Build of gcc on Cygwin WinXp SP2
On 03 May 2007 03:41, Aaron Gray wrote: Various people run the testsuite on cygwin every now and again; check the gcc-testresults@ mailinglist archive. Yes, Tim has allready run it :- http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg01540.html I haven't done one for weeks now Looks like there are some real problems with GCC-4.3-20070427. It fails to compile LLVM on both Cygwin and Linux producing rogue error messages and some weird bugs. Aaron Aaron
Re: gcov in cross-compile: have a patch, seek direction
On Thu, 2007-05-03 at 19:55 +0200, Danny Backx wrote: > Ok, a command line option is what I have. I'll try to clean up my > patch shortly, and see if it still applies cleanly in a recent gcc > tree. Our current version is based on gcc-4.1.0. Or is a patch against > that ok ? This feature would not be accepted into GCC 4.1 or 4.2, so please bring your patch up to date with mainline and then submit it. I'd be surprised if it's much work to do that. Cheers, Ben
Re: A problem with the loop structure
Hello, > ii) > In loop_version there are two calls to loop_split_edge_with > 1. loop_split_edge_with (loop_preheader_edge (loop), NULL); > 2. loop_split_edge_with (loop_preheader_edge (nloop), NULL); > nloop is the versioned loop, loop is the original. > > loop_split_edge_with has the following: > new_bb = split_edge (e); > add_bb_to_loop (new_bb, loop_c); > > 1) When we get to the fist call, nloop->outer->num_nodes = 8 while dfs > returns 6. then the problem is before this call; you need to check which two blocks that are marked as belonging to nloop->outer in fact do not belong to this loop, and why. Zdenek
Re: 2nd quarter of 2007 and no GPL code of Java from Sun.
Fernando Lozano wrote: Hi Pizarro, Today is 01 of May, the worker's day. I've not the code in May, Fernando. How long have i to wait? Just google around to find when JavaOne will be held. Just as I said on my original post. JavaOne starts May 8. Besides, the Worker's day is a holiday in most of the world, so don't expect Sun to be working on May 1st to relase the code and give a press conference about that. ;-) Just be a little patient. Don't you remember the work and time it took to Netscape when decided to open their browser? Java is a much bigger code base. The engineer's definition of "available in May" is May 1. The marketer's definition of "available in May" is May 30. -- Michael Eager[EMAIL PROTECTED] 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: 2nd quarter of 2007 and no GPL code of Java from Sun.
On Thu, May 03, 2007 at 06:29:29PM -0700, Michael Eager wrote: > The engineer's definition of "available in May" is May 1. > The marketer's definition of "available in May" is May 30. Nope. The engineer's definition of "available in May" depends on whether the engineer needs the item (then it's May 1) or is responsible for producing the item (then it's May 31 at midnight).
Re: Bootstrap comparison differnce(s) on cygwin with 4.2.0 RC3: ./ada/exp_aggr.o differs
On 5/2/07, Christian Joensson <[EMAIL PROTECTED]> wrote: 2007/5/2, Andrew Haley <[EMAIL PROTECTED]>: > Christian Joensson writes: > > On cygwin, with D. Korn's proposed patch to cygwin's (i.e., newlib's) > > stdio.h, I get a bootstrap failure do to comparison difference(s): > > Did you do a total rebuild of all gcc in a clean directory? You need > to. yep, started from scratch with the tarball... here's how I configured it: $ ./stage3-gcc/xgcc.exe -v Using built-in specs. Target: i686-pc-cygwin Configured with: ../gcc/configure --disable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --with-system-zlib --enable-threads=posix --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang Thread model: posix gcc version 4.2.0 20070501 (prerelease) [EMAIL PROTECTED] /usr/local/src/branch/objdir $ btw, did it work for you? -- Cheers, /ChJ I get the exact same errors when using a pristine tar ball. Using built-in specs. Target: i686-pc-cygwin Configured with: ../configure -disable-nls --without-included-gettext --enable-version-specific-libs --without-x --enable-libgcj --with-system-zlib --enable-threads=posix --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,treelang --prefix=/cygdrive/c/beta --program-suffix=-4.2rc3 Thread model: posix gcc version 4.2.0 20070501 (prerelease) Regards, JT
