I will pull a patch together tomorrow. There is currently nothing in
the code for keeping the region stuff up to date as changes are made to
the cfg. For most changes this would not be hard, but for some it is
really hard.
Daniel Berlin wrote:
On Thu, 2005-09-22 at 18:49 -0700, Devang Pate
Mike Stump <[EMAIL PROTECTED]> writes:
| On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote:
| > Looking into it further, I've found:
| >
| > From Bugzilla Bug 23628:
| > > --- Additional Comment #9 From Mat Marcus 2005-08-29 20:44
| > [reply]
| > > Sorry, I was a bit slop
On Thu, 2005-09-22 at 18:49 -0700, Devang Patel wrote:
> On Sep 22, 2005, at 2:32 AM, Steven Bosscher wrote:
>
> > On Sep 22, 2005 11:25 AM, Zdenek Dvorak
> > <[EMAIL PROTECTED]> wrote:
> >
> >>> 4. Other ideas?
> >>>
> >>
> >> Preserving the information about loops throughout the
> >> optimiz
On Sep 22, 2005, at 2:32 AM, Steven Bosscher wrote:
On Sep 22, 2005 11:25 AM, Zdenek Dvorak
<[EMAIL PROTECTED]> wrote:
4. Other ideas?
Preserving the information about loops throughout the
optimizations, and
just keeping this information attached at the loop description
would by
far
Mike Stump wrote:
On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote:
Looking into it further, I've found:
From Bugzilla Bug 23628:
> --- Additional Comment #9 From Mat Marcus 2005-08-29 20:44
[reply]
> Sorry, I was a bit sloppy--I didn't remove all intermediate la
Hank Kester wrote:
On 9/22/05, Jonathan Turkanis wrote:
>> > M-x grep VISIBILITY tells you the answer.
>> What are you grepping?
> Why, the source code to gcc of course.
Let's go back a bit:
Mike Stump wrote:
If the implication is that users should grep the source code before asking
On 9/22/05, Jonathan Turkanis <[EMAIL PROTECTED]> wrote:
> >> > M-x grep VISIBILITY tells you the answer.
> >> What are you grepping?
> >
> >
> >
> > Why, the source code to gcc of course.
>
>
> Let's go back a bit:
>
> Mike Stump wrote:
>
> > Jonathan Turkanis wrote:
> > > So it seems a
>The POSIXy way to do that would be to refer to the LC_CHARSET
>environment variable, but then consider
>
>LC_CHARSET=UTF-16 c99 foo.c
>
>where 'foo.c' is in UTF-16 and contains '#include ',
Not really a problem for a number of reasons. First, it's LC_CTYPE
you're thinking of. Second, the narrow
On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote:
Looking into it further, I've found:
From Bugzilla Bug 23628:
> --- Additional Comment #9 From Mat Marcus 2005-08-29 20:44
[reply]
> Sorry, I was a bit sloppy--I didn't remove all intermediate layers
> from my test e
Ian Lance Taylor wrote:
Jonathan Turkanis writes:
I'm getting tired of this. You assumed I'm must have meant something
else than what I plainly asked; once I mentioned that I was writing a
book, you realized I really meant what I said.
That's pretty much it, yes.
Many years of experience
Mike Stump wrote:
> On Wednesday, September 21, 2005, at 09:13 PM, Jonathan Turkanis wrote:
>
>> > Telling users to supply that flag is useless. It is the default.
>>
>> It's advertised as the default, but the threads I cited in my last post
suggest
> The only time that it would matter is wh
Paul Eggert <[EMAIL PROTECTED]> writes:
> Thanks, everybody, for writing about this.
>
> The standardization process is one of consensus, and if the GCC
> developers find some areas of disagreement here I think it unlikely
> that the other POSIX implementers will agree with the proposed action.
>
Snapshot gcc-4.0-20050922 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050922/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050922
You'll
On Wednesday, September 21, 2005, at 09:13 PM, Jonathan Turkanis wrote:
> Telling users to supply that flag is useless. It is the default.
It's advertised as the default, but the threads I cited in my last
post suggest
The only time that it would matter is when the command line has on it a
On Sep 22, 2005, at 4:21 PM, Fariborz Jahanian wrote:
Following patch avoids this problem. If this is OK, I will submit a
patch when fsf mainline is unfrozen.
The FSF mainline is not frozen, only the 4.0 release branch.
Thanks,
Andrew Pinski
In a given test case with 128 bit mmx intrinsics, routine
make_compound_operation (in combine.c) attempts to do a sign-extract
of the middle 64bit of the 128 bit (TImode) register. Pattern we have
is:
(lshiftrt:TI (ashift:TI (subreg:TI (reg/v:V2DI 75
[ vu16YPrediction3 ]) 0) (const_int 32
Liu Haibin <[EMAIL PROTECTED]> writes:
> I compiled the following code using nios gcc -da -O3 (gcc version 3.3.3)
>
> #include
> #define PI (4*atan(1))
>
> double rad2deg(double rad)
> {
> return (180.0 * rad / (PI));
> }
>
> The begining of the .s file is
> rad2deg:
> addi
FYI:
On the web page:
http://gcc.gnu.org/mirrors.html
the link:
http://strawberry.resnet.mtu.edu/pub/gcc/
fails: "The requested URL /pub/gcc/ was not found on this server"
-- George Young
--
"Are the gods not just?" "Oh no, child.
What would become of us if they were?" (CSL)
On 9/22/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> The GCC 4.0.2 RC3 prerelease is spinning now.
>
> If all goes well, it will be available later today.
whoa, I get a few regressions here, compare this with
http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01019.html ...
LAST_UPDATED: Thu Sep
On Thursday 22 September 2005 19:31, Daniel Jacobowitz wrote:
> On Thu, Sep 22, 2005 at 12:50:39PM -0400, Robert Dewar wrote:
> > of course, but the behavior of a compiler with a special implementation
> > dependent switch is not specified by the standard! Switches can do any
> > amount of violence
Hi Jan,
I think fixup_reorder_chain contains questionable code to cope with a
pathological case:
/* The degenerated case of conditional jump jumping to the next
instruction can happen on target having jumps with side
effects.
Crea
On Thu, Sep 22, 2005 at 12:50:39PM -0400, Robert Dewar wrote:
> of course, but the behavior of a compiler with a special implementation
> dependent switch is not specified by the standard! Switches can do any
> amount of violence to the standard you like, the only requirement is
> that there be a d
> > I have. I am awaiting solaris test details.
>
> Not very good: regressions on Solaris 2.6, 7, 8 and 9.
>
> FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
> FAIL: ext/mt_allocator/check_delete.cc execution test
> FAIL: ext/mt_allocator/check_new.cc execution test
> FAIL:
> The GCC 4.0.2 RC3 prerelease is spinning now.
Regressions on Solaris 2.6, 7, 8 and 9:
FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
FAIL: ext/mt_allocator/check_delete.cc execution test
FAIL: ext/mt_allocator/check_new.cc execution test
FAIL: ext/mt_allocator/deallocate_g
> I have. I am awaiting solaris test details.
Not very good: regressions on Solaris 2.6, 7, 8 and 9.
FAIL: ext/mt_allocator/check_allocate_big_per_type.cc execution test
FAIL: ext/mt_allocator/check_delete.cc execution test
FAIL: ext/mt_allocator/check_new.cc execution test
FAIL: ext/mt_allocator
> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
Gerald> On Thu, 22 Sep 2005, Tom Tromey wrote:
>> I think it depends a lot on timing; the sooner 4.1 ships the less
>> inclined I would be to do another import. I want to see 4.1 ship with
>> a reasonably up-to-date class library, thoug
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> What version of CVS are you using, and does it speak the "-X"
Dave> option (new in 1.12.x)?
Thanks! I didn't know that this was added; this addresses one of the
biggest problems I've had with cvs import over the years. I'll try
this
Mark Mitchell wrote:
The GCC 4.0.2 RC3 prerelease is spinning now.
If all goes well, it will be available later today.
From an RTEMS perspective, 4.0.2RC2 with no patches appeared to
be at least as good as 4.0.1 w/RTEMS patches. I spotted no
new issues. I built a native C, C++, and Ada compi
Dave Korn wrote:
Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?
Both outputs are "correct".
No, the standard is entirely unambiguous:
of course, but the behavior of a compiler with a special implementation
de
John Love-Jensen <[EMAIL PROTECTED]> writes:
| Hi Dave, Daniel, and Gaurav,
|
| For C99, I stand corrected.
|
| For C89 or C++98, I think my statement is applicable.
No, for C++98 your statement is even more incorrect because
enumerators (the constants) are NOT of type int -- and that has been
Hi Gaby, Dave, Daniel, and Gaurav,
>This is incorrect and misleading.
I concur. I retract my previous statement, and direct
seekers-of-clarification to the previous posts that answered this issue. My
apologies for my confusion.
Sincerely,
--Eljay
Hi Dave, Daniel, and Gaurav,
For C99, I stand corrected.
For C89 or C++98, I think my statement is applicable. (But until I
double-check by reading those standards, take that with a grain of salt.)
For all three, having enum be an int (signed or unsigned) is legit of
course.
For all three, hav
John Love-Jensen <[EMAIL PROTECTED]> writes:
| Hi Gaurav,
|
| >Please confirm which of the two outputs is correct and why is there a
| difference in the output of two versions of compiler?
|
| Both outputs are "correct".
|
| (Neither output is compliant to the standard, of course, as -fshort-en
Original Message
>From: John Love-Jensen
>Sent: 22 September 2005 16:34
> Hi Gaurav,
>
>> Please confirm which of the two outputs is correct and why is there a
> difference in the output of two versions of compiler?
>
> Both outputs are "correct".
>
No, the standard is entirely unam
On Thu, Sep 22, 2005 at 10:34:19AM -0500, John Love-Jensen wrote:
> Hi Gaurav,
>
> >Please confirm which of the two outputs is correct and why is there a
> difference in the output of two versions of compiler?
>
> Both outputs are "correct".
>
> (Neither output is compliant to the standard, of c
The GCC 4.0.2 RC3 prerelease is spinning now.
If all goes well, it will be available later today.
FYI,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Hi Gaurav,
>Please confirm which of the two outputs is correct and why is there a
difference in the output of two versions of compiler?
Both outputs are "correct".
(Neither output is compliant to the standard, of course, as -fshort-enums is
a deviation from the standard.)
Sincerely,
--Eljay
Gaurav Gautam, Noida wrote:-
> #include
> int main()
> {
>enum aa {
>a = 0, b =127 , c
>};
> printf("size = %d %d %d\n", sizeof(enum aa),sizeof(b),sizeof(c));
> printf("value= %d %d %d\n", a,b,c);
> return 0;
> )
>
> The output is
> size = 1 1 1
> value= 0 127 128
> when
Daniel Berlin <[EMAIL PROTECTED]> writes:
> > The builtins table is initialized with a separate .def file, but it
> > boils down to initializers this:
> >
> > { code, "__builtin_name", C2_INT,
> >{ C2_INT, C2_VPTR, C2_NONE, C2_NONE, C2_NONE, C2_NONE } },
> >
> > This way I only have to wri
On Thu, 22 Sep 2005, Tom Tromey wrote:
> I think it depends a lot on timing; the sooner 4.1 ships the less
> inclined I would be to do another import. I want to see 4.1 ship with
> a reasonably up-to-date class library, though; for one thing the more
> recent the library, the more apps we can run.
> "David" == David Daney <[EMAIL PROTECTED]> writes:
>> I'm finally ready to do another classpath import,
David> Do you plan on another classpath import before the 4.1 release?
I think it depends a lot on timing; the sooner 4.1 ships the less
inclined I would be to do another import. I want
Original Message
>From: [EMAIL PROTECTED]
>Sent: 22 September 2005 15:25
>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
>
>>> I'm finally ready to do another classpath import, and near the last
>>> minute I realized that the import may temporarily break the build, due
>>> to an un
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
>> I'm finally ready to do another classpath import, and near the last
>> minute I realized that the import may temporarily break the build, due
>> to an unfortunate interaction between the classpath Makefile and the
>> way cvs import works. F
Thanks for the reply, but I did not get the answer to my question.
My question is:
In the below mentioned program
#include
int main()
{
enum aa {
a = 0, b =127 , c
};
printf("size = %d %d %d\n", sizeof(enum aa),sizeof(b),sizeof(c));
printf("value= %d %d %d\n", a,b,c);
return 0;
)
> The builtins table is initialized with a separate .def file, but it
> boils down to initializers this:
>
> { code, "__builtin_name", C2_INT,
>{ C2_INT, C2_VPTR, C2_NONE, C2_NONE, C2_NONE, C2_NONE } },
>
> This way I only have to write the type in one place, I only create the
> function ty
Hello [EMAIL PROTECTED]
sgserv# srcdir/config.guess
i386-unknown-freebsd5.3
sgserv# /usr/local/bin/gcc -v
Using built-in specs.
Target: i386-unknown-freebsd5.3
Configured with: ../srcdir/configure --with-arch=athlon-4 --with-tune=athlon-4
Thread model: posix
gcc version 4.0.1
The following langu
Hi all,
first of all, sorry for possible double post, I just didn't get any
answers from gcc-help-mailing list.
I'm trying to compile OpenSSH 0.9.8 with gcc 3.4.3 (64-bit) on a HP-UX.11i
and collect2 utility is doing something odd (as far as I can tell). It is
linking libgcc twice (I guess becaus
Hi,
I compiled the following code using nios gcc -da -O3 (gcc version 3.3.3)
#include
#define PI (4*atan(1))
double rad2deg(double rad)
{
return (180.0 * rad / (PI));
}
The begining of the .s file is
rad2deg:
addisp, sp, -16
stw fp, 8(sp)
mov r6
Original Message
>From: Tom Tromey
>Sent: 21 September 2005 20:31
> I'm finally ready to do another classpath import, and near the last
> minute I realized that the import may temporarily break the build, due
> to an unfortunate interaction between the classpath Makefile and the
> way cvs
On Sep 22, 2005 11:25 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> > 4. Other ideas?
>
> Preserving the information about loops throughout the optimizations, and
> just keeping this information attached at the loop description would by
> far be the cleanest approach -- admitedly also the one tha
Hello,
> As a follow up to http://gcc.gnu.org/ml/gcc/2005-04/msg00461.html
>
> I would like to improve SMS by passing data dependencies information
> computed in tree-level to rtl-level SMS. Currently data-dependency graph
> built for use by SMS has an edge for every two data references (i.e. it'
David Daney writes:
> Tom Tromey wrote:
> > I'm finally ready to do another classpath import,
>
> Do you plan on another classpath import before the 4.1 release?
This is an interesting question. Potentially, a classpath import can
have a hugely destabilizing effect. However, IMO each Classp
1. Introduce a new BB bit flag and set it for the header BB of a loop that
has no data dependencies. This approach already works, but only if the old
loop optimizer (pass_loop_optimize) is disabled (otherwise the bit doesn't
survive).
Which will happen in 4.2.
One potential problem is that t
53 matches
Mail list logo
