On Tue, 29 Nov 2005, Andrew Pinski wrote:
I threw the current version of the patch up here:
http://nondot.org/sabre/llvm-gcc-4.0-patch.tar.gz
A couple of comments.
getIntegerType is really badly. It seems better to use
the mode to detect the type.
Also maping 128bit fp type to {double, dou
>
>
> I threw the current version of the patch up here:
> http://nondot.org/sabre/llvm-gcc-4.0-patch.tar.gz
A couple of comments.
getIntegerType is really badly. It seems better to use
the mode to detect the type.
Also maping 128bit fp type to {double, double} seems wrong
for almost all targe
On Mon, 28 Nov 2005, Hans-Peter Nilsson wrote:
> I've attached the work-in-progress
If someone's missing the trivial sim-main-glue.c, here it is,
just for completeness. Not used for "native" testing.
brgds, H-P/* Glue for passing arguments to a simulator that can't pass
command-line arguments
>
> --nextPart1783728.bJoWQadrrL
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
>
> I had some problems when trying to use the apple branch on a gnu/linux/x86.=
> =20
> Because of this I am trying to port the patch to
On Mon, 28 Nov 2005, Mike Stump wrote:
> On Nov 28, 2005, at 6:21 PM, Hans-Peter Nilsson wrote:
> > I've attached the work-in-progress so I don't have to get into
> > detail about what it does :-) except noting that you'll see in
> > gcc.sum something like:
> >
> > PASS: csibe -O1 runtime zlib-1.1.
> There is an upsteam for beohm_gc (Boehm himself).
Yes, but you usually can modify the local copy and simply CC Hans.
--
Eric Botcazou
Gabriel Dos Reis wrote:
I would need an ia64 maintainer to comment on this. From
There isn't enough ia64 maintainer bandwidth to provide detailed
comments on testsuite results on old machines with old tools versions.
Basically, it is only me, and I'm also trying to do a hundred other
things
Jim Wilson <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > At the moment, we have only one bug I consider release critical for 3.4.5.
| > middle-end/24804 Produces wrong code
|
| I put an analysis in the PR. It is a gcse store motion problem.
Woaw! Thanks for the detailed ana
Is this indeed a bug?
Sounds like a bug.
I just found something in the bug database relating to this:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19232
According to Andrew (#3) it doesnt eject a warning becuase
the function isn't inlined. I'm not sure thats a valid
reason for not ejecting th
Nemanja Popov wrote:
.../../gcc/libgcc2.c:535: error: unable to find a register to spill in
class GR_REGS
Reload is one of the hardest parts to get right with an initial port.
You will probably have to spend some time learning the basics of what
reload does.
There are many different things
Gabriel Dos Reis wrote:
At the moment, we have only one bug I consider release critical for 3.4.5.
middle-end/24804 Produces wrong code
I put an analysis in the PR. It is a gcse store motion problem.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
On Nov 28, 2005, at 6:21 PM, Hans-Peter Nilsson wrote:
I've attached the work-in-progress so I don't have to get into
detail about what it does :-) except noting that you'll see in
gcc.sum something like:
PASS: csibe -O1 runtime zlib-1.1.4:minigzip not slower than best
PASS: csibe -O1 runtime zl
I had some problems when trying to use the apple branch on a gnu/linux/x86.
Because of this I am trying to port the patch to the trunk. With some help
from Chris I am now able to build xgcc, but a type check fails when it is
run:
../../trunk-llvm/gcc/crtstuff.c:186: internal compiler error: tre
David Edelsohn wrote:
> Swox AB does have a copyright assignment on file, so GCC is free
> to use ieeelib.c.
Great. Thanks for double-checking!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
On Mon, 28 Nov 2005, Jim Wilson wrote:
> The DWARF2 unwind info method has little or no overhead until a
> exception is thrown. This is the preferred method for most targets. In
> this scheme, we read the DWARF2 unwind info from the executable when an
> exception is throw, parse the unwind tables
Again, that's a strawman. I'm just looking for suggestions about what
we might to do -- or even feedback that there's no need to do anything.
This isn't really suitable for an automated tester, but what I used to do was
keep around some .i files of some version of some compiler files (I t
> Mark Mitchell writes:
Mark> In his original message, Torbjorn indicated that Swox AB (the company of
Mark> which he is CEO) donated the code, and the old copyright file had an
Mark> entry for Torbjorn, though not Swox AB. I've contacted Torbjorn, and
Mark> he'd still like to see ieeelib.c i
Joe Buck wrote:
> Well, the problem is that you're raising a legal technicality, and legal
> technicalities are up to the FSF. Maybe they'll have no problem,
> especially if Swox AB basically is Torbjorn. If there is a problem, and
> Torbjorn is still CEO of Swox AB, it should be no problem (oth
On Mon, Nov 28, 2005 at 06:05:34PM -0800, Mark Mitchell wrote:
> Back in 1999, Torbjorn Granlund posted:
>
> http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html
>
> That message contains an IEEE floating-point emulation library, like
> fp-bit.c. Howeve, the performance is considerably better; Josep
On Tue, Nov 29, 2005 at 02:03:46AM +, Paul Brook wrote:
> > I was hoping that having it there when people did test runs would change
> > the psychology; instead of having already checked in a patch, which
> > we're then looking to revert, we'd be making ourselves aware of
> > performance impact
Back in 1999, Torbjorn Granlund posted:
http://gcc.gnu.org/ml/gcc/1999-07n/msg00553.html
That message contains an IEEE floating-point emulation library, like
fp-bit.c. Howeve, the performance is considerably better; Joseph
measured against fp-bit.c with a modern compiler, and ieeelib.c is about
> I was hoping that having it there when people did test runs would change
> the psychology; instead of having already checked in a patch, which
> we're then looking to revert, we'd be making ourselves aware of
> performance impact before check-in, even for patches that we don't
> expect to have pe
On Nov 28, 2005, at 4:38 PM, Mark Mitchell wrote:
we require people to run regression tests for correctness, but that
we don't really have anything equivalent for performance.
My feeling is that we should have such a suite. I'd favor a micro
style, where we are measuring clock cycles (on ma
Joe Buck wrote:
> It would be possible to detect performance regression after fact, but
> soon enough to look at reverting patches. For example, given multiple
> machines doing SPEC benchmark runs every night, the alarm could be raised
> if a significant performance regression is detected.
Right
On Mon, Nov 28, 2005 at 04:38:58PM -0800, Mark Mitchell wrote:
> Clearly, performance testing is harder than correctness testing;
> correctness is binary, while performance is a continuum. Machine load
> affects performance numbers. It's reasonable to strive for no
> correctness regressions, but
Kövesdi György wrote:
I built an environment for my 68020 board using gcc-4.0.2 and
newlib-1.13.0. Everything seems good, but the exception handling is not
working.
Getting EH to work for a newlib using target board may be complicated.
How EH works depends on whether you are using DWARF2 unwin
Frank Cusack wrote:
See http://bugzilla.redhat.com/bugzilla> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
- the bug is quite reproducible, why does gcc say otherwise?
This is due to a patch that Red Hat has added to the FSF gcc sources.
When a Red Ha
>
> Andrew Haley wrote:
> > Bernd Schmidt writes:
>
> > > Hmm, we can trap null pointer accesses, but I don't think we deliver
> > > reliable SIGSEGV signals yet or provide a means of getting the faulting
> > > address. If that was fixed, is there anything obvious that stands in
> > > the
Andrew Haley wrote:
Bernd Schmidt writes:
> Hmm, we can trap null pointer accesses, but I don't think we deliver
> reliable SIGSEGV signals yet or provide a means of getting the faulting
> address. If that was fixed, is there anything obvious that stands in
> the way of a uClinux/uClibc
We're collectively putting a lot of energy into performance improvements
in GCC. Sometimes, a performance gain from one patch gets undone by
another patch -- which is itself often doing something else beneficial.
People have mentioned to me that we require people to run regression
tests for corre
Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| Tests (including Ada tests this time) for i686-pc-linux-gnu on RHEL 3.0
| are at
|
| http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01334.html
|
| They are essentially perfect (only the one known failure).
|
| I also ran tests on an x86_64-unknown
and testing here:
>
>ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.5-20051128/
Tests (including Ada tests this time) for i686-pc-linux-gnu on RHEL 3.0
are at
http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01334.html
They are essentially perfect (only the one known failure).
I also ran tests on a
On Mon, Nov 28, 2005 at 12:45:41AM -0800, Jim Blandy wrote:
> On 11/27/05, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > Yes, I know it's a wiki and I can do this myself, but I only have so
> > much spare time and maybe the second one was added for a good reason.
>
> http://en.wikipedia.org/wiki/
Laurent GUERBY wrote:
On Mon, 2005-11-28 at 14:10 +0100, Paolo Bonzini wrote:
Then, I don't know if it would be legal to optimize
struct r {
unsigned int x : 7;
volatile unsigned int y : 1;
};
struct r my_reg;
So that my_reg.x is accessed with a non-volatile mem, and my_reg.y i
>
> On Nov 28, 2005, at 12:40 PM, Andrew Pinski wrote:
> > I was, there was no where in I was saying we should break ISO standard
>
> The effect of following Ada's rules:
>
> > While it is true that GCC is not just an Ada compiler but I think
> > we should
> > follow a sane set of rules for GN
Hi,
this question is not about development of GCC so should be moved to
either [EMAIL PROTECTED] or [EMAIL PROTECTED] - I suggest the
former. Please send any other replies to the libstdc++ list, thanks.
On Mon, Nov 28, 2005 at 02:03:21PM +0530, [EMAIL PROTECTED] wrote:
> I have moved to gcc vers
On Nov 28, 2005, at 12:40 PM, Andrew Pinski wrote:
I was, there was no where in I was saying we should break ISO standard
The effect of following Ada's rules:
While it is true that GCC is not just an Ada compiler but I think
we should
follow a sane set of rules for GNU C which might mean fol
On Mon, 2005-11-28 at 14:10 +0100, Paolo Bonzini wrote:
> Then, I don't know if it would be legal to optimize
>
>struct r {
> unsigned int x : 7;
> volatile unsigned int y : 1;
>};
>
>struct r my_reg;
>
> So that my_reg.x is accessed with a non-volatile mem, and my_reg.y is
Tom Tromey writes:
>
> Java is fairly dynamic, as I'm sure you know. So, I'm much more
> interested in the JITting possibilities than in link time
> optimizations; the latter is cool and probably useful to embedded
> users of gcj, but I'd imagine for all our recent binary compatibility
> de
> "Chris" == Chris Lattner <[EMAIL PROTECTED]> writes:
Chris> In this role, it provides a static optimizer, interprocedural link-
Chris> time optimizer, JIT support, and several other features.
I'm quite interested in the JIT aspect of LLVM, for gcj.
This would fill one of our major missing g
On Nov 28, 2005, at 10:42 AM, Kean Johnston wrote:
* gcc.dg/assign-warn-3.c: Ditto.
Why in the world do you imagine this should depend on -fpic?
And here is the case that fails (-fPIC). I have no idea why those
warnings are not being ejected when compiling with -fPIC. Perhaps I
discovere
>
> On Nov 28, 2005, at 10:55 AM, Richard Kenner wrote:
> > It's not that simple and I suspect you know it.
>
> Yes, this is all fine and very well, but do you realize that Andrew
> wanted to break gcc behavior as mandated by the ISO standard? This
> is very, very simple. The answer is no.
> "Chris" == Chris Lattner <[EMAIL PROTECTED]> writes:
>> Only the Ada frontend seems to be in a state to maybe support direct
>> frontend IR to LLVM translation.
Chris> Sure, also maybe Fortran?
FWIW gcjx was designed to make this easy to do. And just yesterday a
volunteer started working
On Nov 28, 2005, at 10:55 AM, Richard Kenner wrote:
It's not that simple and I suspect you know it.
Yes, this is all fine and very well, but do you realize that Andrew
wanted to break gcc behavior as mandated by the ISO standard? This
is very, very simple. The answer is no. I'm not budgi
Gabriel Dos Reis wrote:
| I do agree that if
|
| a) everyone agrees on what the "sensible" definition is
We do have a standard definied beahviour.
in one case, and of course we must adhere to this,
but not in the other case
| b) the optimization is not valuable
for those people who don't
Robert Dewar <[EMAIL PROTECTED]> writes:
[...]
| I do agree that if
|
| a) everyone agrees on what the "sensible" definition is
We do have a standard definied beahviour.
| b) the optimization is not valuable
for those people who don't care about the standard semantics, there is
always an opti
Mike Stump wrote:
Only in one direction does the standard make it undefined, as I
quoted. I know why they do this, and I am arguing that that latitude
should not be used to try and `optimize' things to make them behave
differently (such as calling abort for example) in the presence of
vo
On Nov 28, 2005, at 11:12 AM, Robert Dewar wrote:
Mike Stump wrote:
I disagree. For example, there is behavior mandated by the
Standard for C, such as this, that, reasonably, I think we have
to follow. You can argue that we don't have to follow the
standard but I'm not just going to li
On Nov 28, 2005, at 11:05 AM, Robert Dewar wrote:
Right, I agree, I was answering whether this can ever be done
legitimately, and the answer is really no, it is undefined in
C
It is not.
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| I'm running the pre-releasing script, so a new prerelease tarball will be
| available today.
The tarballs are available for download and testing here:
ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.5-20051128/
-- Gaby
Mike Stump wrote:
I disagree. For example, there is behavior mandated by the Standard
for C, such as this, that, reasonably, I think we have to follow. You
can argue that we don't have to follow the standard but I'm not just
going to listen to you.
Hmm, I guess I misread the standard, I
Mike Stump wrote:
gcc is not just an Ada compiler. Clearly, the answer has to be yes to
support GNU C.
Right, I agree, I was answering whether this can ever be done
legitimately, and the answer is really no, it is undefined in
C, and if you manage to do it in Ada, which you can if you
really
Mark Mitchell <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
|
| > Mark, RTH, could you provide hints?
|
| I don't have any ideas, just from looking atthe problem. It could be a
| stack allocation problem, where we assign two things the same stack
| slot, and get confused.
Thanks!
-- G
He said we can do anything, this is untrue. I rail against the casual
use of the word because it misleads others into believing it, and then
proposing patches that do anything they want, and yet make gcc worse.
I realize there that we have no documentation person that writes down
All,
This is from an email trail on gcc-patches. I was attempting to clean
up differences in the test suite between -fPIC and no -fPIC tests.
* gcc.dg/assign-warn-3.c: Ditto.
Why in the world do you imagine this should depend on -fpic?
Here's the case that passes (no -fPIC):
Execut
On Nov 28, 2005, at 10:08 AM, Joe Buck wrote:
So then clearly, since it means anything, we can change gcc to accept
pascal instead of C? Right? This is absurd.
Mike, you wrote "GNU C", not "ISO C". There's no spec for the former.
He said we can do anything, this is untrue. I rail against
On Nov 28, 2005, at 9:29 AM, Dave Korn wrote:
BTW, I never did manage to find the patches you referred to in
your postings
from summer 2000. Googling for "mike stump volatile_ok" just kept
on finding
me the post where you were advising someone to find your patches by
searching
for your na
On Mon, Nov 28, 2005 at 09:53:31AM -0800, Mike Stump wrote:
> On Nov 28, 2005, at 9:41 AM, Andrew Pinski wrote:
> >Huh? they are not carefully written at all. This is why I said what
> >is GNU C? Again the language is not written out so it means anything.
>
> So then clearly, since it means anyt
On Nov 28, 2005, at 9:41 AM, Andrew Pinski wrote:
Huh? they are not carefully written at all. This is why I said what
is GNU C? Again the language is not written out so it means anything.
So then clearly, since it means anything, we can change gcc to accept
pascal instead of C? Right? Thi
On Nov 28, 2005, at 9:33 AM, Richard Kenner wrote:
And where is the standard for the language known as "GNU C"?
You can obtain the ISO definition for C from ISO:
61)The intent of this list is to specify those circumstances
in which an object may or may not be aliased.
>
> On Nov 28, 2005, at 9:18 AM, Andrew Pinski wrote:
> > While it is true that GCC is not just an Ada compiler but I think
> > we should
> > follow a sane set of rules for GNU C which might mean following
> > Ada's rules
> > for this case.
>
> Because GNU C doesn't have rules carefully writt
On Nov 28, 2005, at 9:18 AM, Andrew Pinski wrote:
While it is true that GCC is not just an Ada compiler but I think
we should
follow a sane set of rules for GNU C which might mean following
Ada's rules
for this case.
Because GNU C doesn't have rules carefully written to make this
impossib
Mike Stump wrote:
> On Nov 28, 2005, at 3:00 AM, Richard Earnshaw wrote:
>> Possibly, but I think the more interesting observation is listed in
>> parenthesis: Can a volatile access ever alias a non-volatile access?
>> Logic would suggest that a program is unpredictable if written in such a
>> way
>> Possibly, but I think the more interesting observation is listed in
>> parenthesis: Can a volatile access ever alias a non-volatile access?
>
> I think the answer is no, Certainly Ada has compile time rules
> carefully written to make this impossible.
gcc is not just an
On Nov 28, 2005, at 9:18 AM, Andrew Pinski wrote:
What is GNU C if it is not well documented?
:-)
^L
Useful.
On Mon, Nov 28, 2005 at 04:10:55PM +0100, Lubos Lunak wrote:
> when gcc emits vague linkage data for C++ like vtables it makes them all
> weak. Is there some reason why this needs to be done?
In the case of vtables, they are only weak if all the virtual functions
are defined as inline. Otherwis
>
> On Nov 28, 2005, at 3:13 AM, Robert Dewar wrote:
> >> Possibly, but I think the more interesting observation is listed in
> >> parenthesis: Can a volatile access ever alias a non-volatile access?
> >
> > I think the answer is no, Certainly Ada has compile time rules
> > carefully written to ma
On Nov 28, 2005, at 3:13 AM, Robert Dewar wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
I think the answer is no, Certainly Ada has compile time rules
carefully written to make this impossible.
g
On Nov 28, 2005, at 3:00 AM, Richard Earnshaw wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
Logic would suggest that a program is unpredictable if written in
such a
way that permits such aliases t
Gabriel Dos Reis wrote:
> Mark, RTH, could you provide hints?
I don't have any ideas, just from looking atthe problem. It could be a
stack allocation problem, where we assign two things the same stack
slot, and get confused.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
On Mon, Nov 28, 2005 at 04:10:55PM +0100, Lubos Lunak wrote:
> Which means that in such case there's no reason to have those symbols weak,
> and having them weak means that the symbol lookup in ld.so for them will be
> more expensive (because it has to search all libraries for a non-weak symbol
On Mon, Nov 28, 2005 at 04:10:55PM +0100, Lubos Lunak wrote:
> when gcc emits vague linkage data for C++ like vtables it makes them all
> weak. Is there some reason why this needs to be done?
>
> If I'm getting it right, based on e.g. on the comment in binutils/bfd/elf.c
> saying that they are
Hello,
when gcc emits vague linkage data for C++ like vtables it makes them all
weak. Is there some reason why this needs to be done?
If I'm getting it right, based on e.g. on the comment in binutils/bfd/elf.c
saying that they are weak in order to allow multiple copies and that the GNU
ld
Hi!
There are several g*dg/compat/ tests failing that show ABI
incompatibilities:
FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_tst.o-cp_compat_y_alt.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t024 cp_compat_x_alt.o-cp_compat_y_tst.o
execute
FAIL: tmpdir-g++.dg-struct-layout-1/t026 cp
Robert Dewar wrote:
Richard Earnshaw wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
I think the answer is no, Certainly Ada has compile time rules
carefully written to make this impossible.
Usua
Richard Earnshaw wrote:
Possibly, but I think the more interesting observation is listed in
parenthesis: Can a volatile access ever alias a non-volatile access?
I think the answer is no, Certainly Ada has compile time rules
carefully written to make this impossible.
Logic would suggest that
On Sun, 2005-11-27 at 03:14, Mike Stump wrote:
> On Nov 22, 2005, at 7:52 AM, Richard Earnshaw wrote:
> > 3) A volatile load isn't moved across any store that may alias (though
> > I'd expect that to be volatile if there's a real risk of aliasning, so
> > maybe we could have another dimension in th
Hi,
At the moment, we have only one bug I consider release critical for 3.4.5.
middle-end/24804 Produces wrong code
This bugs was reported against 3.4.4; it is a bit odd because it is
wrong code generation with '-O3 -fno-strict-aliasing'.
Mark, RTH, could you provide hints?
I'm runni
Alexander wrote:
Hello!
How I can know more about implementation at 'tree' level such
extension as 'typeof'? I am not want to explore and change sources
now, maybe someone cam help?
your two desires conflict. typeof is implemented in cp/rtti.c
nathan
--
Nathan Sidwell:: http:
Hello!
How I can know more about implementation at 'tree' level such
extension as 'typeof'? I am not want to explore and change sources
now, maybe someone cam help?
--
Best regards,
Alexander mailto:[EMAIL PROTECTED]
On 11/27/05, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> Yes, I know it's a wiki and I can do this myself, but I only have so
> much spare time and maybe the second one was added for a good reason.
http://en.wikipedia.org/wiki/Be_bold
Works for them.
Hi,
I have moved to gcc version 3.4.2(linux sll) So I am migrating a
component to this version from gcc 2.96.
In my existing code I am using the *out_waiting* function of the struct
streambuf present in the streambuf.h file.
But I can't find this function in this version of gcc 3.4.2. so can u
82 matches
Mail list logo
