Joel Sherrill <[EMAIL PROTECTED]> wrote:
>
> I'm happy to anounce that Andreas Schwab <[EMAIL PROTECTED]>
> as the new m68k port maintainer.
Kudos!
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
Snapshot gcc-3.4-20050607 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050607/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050607
You'll
In http://gcc.gnu.org/ml/gcc/2005-06/msg00123.html, I mentioned 3 PRs as
being very nice to fix for 4.0.1. There were two others mentioned
subsequently by others. The complete list, then, was:
* 21528
* 21847
* 20928
* 19523
* 21828
As I was preparing this message, RTH fixed 21528. Steven f
Paul Koning wrote:
>>"Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]> writes:
>
>
> Nathanael> * pdp11-*-* (generic only) Useless generic.
>
> I believe this one generates DEC (as opposed to BSD) calling
> conventions, so I'd rather keep it around. It also generates .s files
> that can
On Tue, Jun 07, 2005 at 05:49:54PM -0400, Robert Dewar wrote:
> * Paul Schlie:
>
> > (With an exception being FP optimization, as FP is itself based
> > only on the approximate not absolute representation of values.)
>
> Floating-point arithmetic is not simply some inaccurate representation
> o
Paul Schlie wrote:
- yes, it certainly enables an implementation to generate more efficient
code which has no required behavior; so in effect basically produce more
efficient programs which don't reliably do anything in particular; which
doesn't seem particularly useful?
You keep saying
* Paul Schlie:
(With an exception being FP optimization, as FP is itself based
only on the approximate not absolute representation of values.)
Floating-point arithmetic is not simply some inaccurate representation
of real arithmetic. It can be used this way by the programmer, but in
fact f
Andreas Schwab wrote:
> Bernardo Innocenti <[EMAIL PROTECTED]> writes:
>
>
>>I'm asking because I was planning to replace CVS in our
>>company, but first I wanted to see how good or badly
>>Subversion would perform on a largish project such as GCC.
>
> You might want to ask the KDE project about
Robert Dewar wrote:
Toon Moene wrote:
The first
thing I did after receiving it is wiping out OS X and installing a
real operating system, i.e., Debian.
Is it really necessary to post flame bait like this, hopefully people
ignore this
Perhaps the following little exchange rings a bell:
Mirza Hadzic wrote:
A big endian system is indispensible if you are a compiler writer,
because little endian hardware hides too many programmer errors
Can you show example(s) where little endian hides errors? Just curious...
Sorry, I was already asleep when your mail arrived ...
main()
{
On Tue, Jun 07, 2005 at 11:34:46AM +0530, Atul Talesara wrote:
> Hello folks,
> This might have already been addressed, but I
> tried searching on GCC mailing list archives
> http://gcc.gnu.org/lists.html#searchbox
> and google before posting.
> ...
> My GCC version (cross-compiled to genera
On Tue, 2005-06-07 at 16:08, Jani Monoses wrote:
> Hello
>
> trying to compile the following simple source file using arm-elf-gcc 4.0
>
> void pig(void) __attribute__ ((long_call));
> void pig(void)
> {
> }
>
> yields:
>
> error: conflicting types for 'pig'
> error: previous declaration of 'pig
* Paul Schlie:
>> But the assertion is trivially true. If you impose fewer constraints
>> on an implementation by leaving some cases undefined, it always has
>> got more choices when generating code, and some choices might yield
>> better code. So code generation never gets worse.
>
> - yes, it
Hello
trying to compile the following simple source file using arm-elf-gcc 4.0
void pig(void) __attribute__ ((long_call));
void pig(void)
{
}
yields:
error: conflicting types for 'pig'
error: previous declaration of 'pig' was here
The same with gcc3.3. With other function attributes (isr, sec
> From: Florian Weimer <[EMAIL PROTECTED]>
> * Paul Schlie:
>
>> - I'm not attempting to design a language, but just defend the statement
>> that I made earlier; which was in effect that I contest the assertion
>> that undefined evaluation semantics enable compilers to generate more
>> effic
I'm happy to anounce that Andreas Schwab <[EMAIL PROTECTED]>
as the new m68k port maintainer.
I, for one, thank him and wish him well in this effort. :)
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me
"Rasmussen, David Ravn" <[EMAIL PROTECTED]> writes:
> ***
> Information contained in this email message is intended only for use of the
> individual or entity named above. If the reader of this message is not the
> i
* Paul Schlie:
> - I'm not attempting to design a language, but just defend the statement
> that I made earlier; which was in effect that I contest the assertion
> that undefined evaluation semantics enable compilers to generate more
> efficient useful code by enabling them to arbitrarily de
> From: Robert Dewar <[EMAIL PROTECTED]>
> Paul Schlie wrote:
> Fine, but then you are designing a different language from C.
- I'm not attempting to design a language, but just defend the statement
that I made earlier; which was in effect that I contest the assertion
that undefined evaluation
On Tue, Jun 07, 2005 at 11:41:34AM +0300, [EMAIL PROTECTED] wrote:
> Dear Diego,
>
> is the newest version of your pass (including the June 01 modifications at
> gcc-patches) applicable to all statements in a basic block and not only to the
> conditionals?
>
You'll have to be more specific. What
David Ayers wrote:
> Ziemowit Laski wrote:
>
>>On 6 Jun 2005, at 22.26, Christian Joensson wrote:
>>
>
> [snip]
>
>>>./bitfield-4.exe: error while loading shared libraries: libobjc.so.1:
>>>cannot open shared object file: No such file or directory
>>>FAIL: obj-c++.dg/bitfield-4.mm execution tes
Ziemowit Laski wrote:
>
> On 6 Jun 2005, at 22.26, Christian Joensson wrote:
>
[snip]
>> ./bitfield-4.exe: error while loading shared libraries: libobjc.so.1:
>> cannot open shared object file: No such file or directory
>> FAIL: obj-c++.dg/bitfield-4.mm execution test
>>
>> Any ideas of what migt
www.opentv.com has a compiler for developing to their platform,
generating OCODE (stack based virtual machine code) from C. Their
compiler is an old gcc 2.6.0 which has been altered somehow.
As I understand it, there were certain problems at the time because gcc
2.6.0 was naturally suited for regi
Bernardo Innocenti <[EMAIL PROTECTED]> writes:
> I'm asking because I was planning to replace CVS in our
> company, but first I wanted to see how good or badly
> Subversion would perform on a largish project such as GCC.
You might want to ask the KDE project about their experience. It's
probably
--- Bernardo Innocenti wrote:
> Hello,
>
> browsing the mailing-list archives, I can't find
> what's
> the current status of the much discussed Subversion
> migration. The topic just appears to have been
> abandoned
> about three months ago.
It's not abandoned, it can be found at
http://gcc.g
Florian Weimer wrote:
* Robert Dewar:
Defintiely not, integer overflow generates async traps on very few
architectures. Certainly synchronous traps can be generated (e.g.
with into on the x86).
Or the JO jump instruction. Modern CPUs choke on the INTO
instruction.
Well INTO is still the
Dear Diego,
is the newest version of your pass (including the June 01 modifications at
gcc-patches) applicable to all statements in a basic block and not only to the
conditionals?
I mean, i saw the gcc-4.0.0 release version (VRP in tree-ssa-dom.c). In this
version two things happen:
a. -fdump-tr
Hello,
browsing the mailing-list archives, I can't find what's
the current status of the much discussed Subversion
migration. The topic just appears to have been abandoned
about three months ago.
Was there agreement on the migration? What would be the most
appropriate time to do it?
I'm asking
* Robert Dewar:
> Defintiely not, integer overflow generates async traps on very few
> architectures. Certainly synchronous traps can be generated (e.g.
> with into on the x86).
Or the JO jump instruction. Modern CPUs choke on the INTO
instruction.
There has been a lot of work recently on making GCC output faster
code. But GCC isn't very fast. On my slow 750MHz Linux box (which the PIII in
it is now R.I.P), it took a whole night to compile 3.4.3.
Sometimes I wonder if Sam Lauber is a Markov generator...
Please read the release notes fo
Paul Schlie wrote:
- Agreed, I would classify any expression as being ambiguous if any of
it's operand values (or side effects) were sensitive to the allowable
order of evaluation of it's remaining operands, but not otherwise.
But this predicate cannot be evaluated at compile time!
Now y
On 6 Jun 2005, at 22.26, Christian Joensson wrote:
I get a few failures when trying to run the obj-c++ testsuite...
See, e.g., http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00375.html
This is what I see in the log file and this is all over... :)
Setting LD_LIBRARY_PATH to
.:/usr/local
32 matches
Mail list logo
