> > A. Convert everything to UCNs in basic source characters as soon
> > as possible, that is, in translation phase 1. (This is what
> > C++ requires, apparently.)
> >
> > B. Use native encodings where possible, UCNs otherwise.
> >
> > C. Convert everything to wide character
Hello,
When building Libgcc with new porting gcc, _floatdidf.o failed for
undefined symbol
_floatsidf. I've been told that _floatsidf is in fpbit.c as
_si_to_df.o. Then I modified the libgcc.mk and firstly build fpbit.
But _pack_df.o failed for undefined symbol
_ashldi3.o which is in libgcc2.c. It
Ross Ridge wrote:
Well, maybe I'm missing something, but it never converts input characters
to UCNs so that means it doesn't do (A) or (B), and the only thing it
converts to wide characters are wide string literals, so it doesn't do
(C).
You are thinking operationally, when you should think se
On Wed, 14 Sep 2005, Paul Eggert wrote:
> So my question is: Is it a burden on GCC to require interpretation (B)?
Yes, but my position remains that we *should* aim to implement (B) and
this is a proper burden to impose.
For how the interpretations can be distinguished, see bug 9449 comments 21
GCC 4.0.1 has been succesfully built on Fedora Core 4
- hardware: Intel Celeron 2.0 GHz 512 MB RAM
- download: gcc-4.0.1.tar.bz2
- installation steps
configure
make bootstrap
make install
- output from running config.guess
i686-pc-linux-gnu
- output of gcc -v
Using b
On Thursday 15 September 2005 10:59, Eric Fisher wrote:
> Hello,
>
> When building Libgcc with new porting gcc, _floatdidf.o failed for
> undefined symbol
> _floatsidf. I've been told that _floatsidf is in fpbit.c as
> _si_to_df.o. Then I modified the libgcc.mk and firstly build fpbit.
> But _pack_
On Sep 15, 2005, Geoffrey Keating <[EMAIL PROTECTED]> wrote:
> On 14/09/2005, at 5:32 PM, Mike Stump wrote:
>> If you output to a temp file, and then mv them to the final file,
>> they will be (I think) safe.
> From the 'make' documentation, node 'Interrupts':
>> If `make' gets a fatal signal w
On Sep 14, 2005, Joe Buck <[EMAIL PROTECTED]> wrote:
> On Wed, Sep 14, 2005 at 02:15:43PM -0300, Alexandre Oliva wrote:
>> Yep, it was pointer subtraction, and GCC actually optimized the
>> division, that could in theory be assumed to be exact, into a
>> multiplication by a large constant (aah, t
Original Message
>From: Paul Brook
>Sent: 15 September 2005 14:25
> On Thursday 15 September 2005 10:59, Eric Fisher wrote:
>> Hello,
>>
>> When building Libgcc with new porting gcc, _floatdidf.o failed for
>> undefined symbol _floatsidf. I've been told that _floatsidf is in
>> fpbit.c as
Hi,
In GDB, when I use the following commands :
$ powerpc-eabi-gdb 543560.elf
GNU gdb 6.1 (eCosCentric)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
Original Message
>From: e.coullien
>Sent: 15 September 2005 15:05
> Hi,
>
> In GDB,
Wrong list. This is the gcc list. You were right first time when you
posted this exact same message to the gdb list half an hour ago.
cheers,
DaveK
--
Can't think of a witty .sigline tod
Dave Korn <[EMAIL PROTECTED]> wrote:
> Wrong list. This is the gcc list. You were right first time when you
> posted this exact same message to the gdb list half an hour ago.
Moreover, people have surely already deleted his message beacuse the
disclaimer at the end of it explicitally says tha
Ulrich Weigand wrote:
> Mark Mitchell wrote:
>
>
>>It's important to test the actual tarballs, rather than CVS, to check
>>for any packaging issues. If you can, download and build the tarballs,
>>post test results to the gcc-testresults mailing list with and
>>contrib/test_summary. If you encou
Laurent GUERBY wrote:
> On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote:
>
>>Assuming that no critical problems emerge, I'll do the final release
>>within the next week.
>
>
> Looks good on x86-linux and x86_64-linux for Ada:
Thanks.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Mark Mitchell wrote:
It's important to test the actual tarballs, rather than CVS, to check
for any packaging issues. If you can, download and build the tarballs,
post test results to the gcc-testresults mailing list with and
contrib/test_summary. If you encounter problems, please file them i
Ross Ridge wrote:
> >Well, maybe I'm missing something, but it never converts input characters
> >to UCNs so that means it doesn't do (A) or (B), and the only thing it
> >converts to wide characters are wide string literals, so it doesn't do
> >(C).
On Thu, Sep 15, 2005 at 07:24:47AM -0400, Rober
On Sep 14, 2005, at 11:55 PM, Geoffrey Keating wrote:
So, I think this is safe.
My build system (GNU make 3.80 on darwin) disagrees with your theory,
I saw two zero length files, created from one -j2 build interrupted
with a normal ^C. I usually never so interrupt builds, so the
probabil
> You are thinking operationally, when you should think semantically.
> Remember that as-if applies here. The rules as stated give ways to
> achieve certain effects, the question is not whether we are following
> the operational rules, but whether we are following the effects.
Thinking semantical
On Sep 14, 2005, at 9:50 PM, Andrew Pinski wrote:
On Sep 14, 2005, at 9:21 PM, Dale Johannesen wrote:
Consider the following SSE code
(-march=pentium4 -mtune=prescott -O2 -mfpmath=sse -msse2)
<4256776a.c>
The first inner loop compiles to
paddq %xmm0, %xmm1
Good. The second compile
On Thu, Sep 15, 2005 at 11:07:23AM -0700, Dale Johannesen wrote:
> Having a more uniform representation for operations on __m128i
> objects would simplify things all over the place, though.
For some definition of "simplify" that doesn't actually make
things simpler when it comes to the autovector
GCC routinely puts on the fly type description in other stabs. For
example,
006c - 00 0002 PSYM argv:p(0,2)=*(0,3)=*(0,4)=r(0,4);0;127;
Now when this PSYM stab is discarded by linker the useful type info
is lost. This happens a lot in -feliminate-unused-debug-symbols mode.
It happ
On Sep 15, 2005, at 2:26 PM, Devang Patel wrote:
I've now patch ready (based on apple-local-200502-branch) but it
requires few bug fixes in darwin GDB. My simple question is : Is
anybody interested in reviewing this GCC patch for acceptance in FSF
GCC (4.1 or 4.2 or whenever) irrespective of
The only issue I can see is that someone who uses an older versions
of Mac OS X but don't have
access to the newer GDB because building Apple's version of GDB is
a little harder than
building than gcc. If you provide a gdb version which is runnable
on All of Mac OS X,
this becomes a littl
Ross Ridge wrote:
Thinking semantically is irrelevent because the question isn't whether GCC
conforms to C99 or POSIX. It clearly doesn't. GCC fails the as-if rule.
The question is one of implementation burden, which can only be answered
by examining GCC's implementation.
Once again we are n
Paolo,
I *think* this problem may have been caused by your reorg of the
pass manager. We are now emitting duplicate dump file numbers:
file.c.t10.cleanup_cfg
file.c.t10.lower
Could you take a look?
Thanks.
Andreas Tobler wrote:
On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote:
Assuming that no critical problems emerge, I'll do the final release
within the next week.
Libgcj seems broken with --enable-java-awt=gtk,xlib --enable-gtk-cairo.
(on darwin ppc and linux ppc at least, but I guess
> It's important to test the actual tarballs, rather than CVS, to check
> for any packaging issues. If you can, download and build the tarballs,
> post test results to the gcc-testresults mailing list with and
> contrib/test_summary.
sh4-unknown-linux-gnu is ok:
http://gcc.gnu.org/ml/gcc-testres
I ran into a problem when chasing down an -mfix-and-continue (an
apple specialty :) code-gen problem.
In a test case, ivopts creates a symbol_ref via a call to
produce_memory_decl_rtl; as in:
if (TREE_STATIC (obj) || DECL_EXTERNAL (obj))
{
const char *name = IDENTIFIER_POI
2005/9/15, Paul Brook <[EMAIL PROTECTED]>:
> On Thursday 15 September 2005 10:59, Eric Fisher wrote:
> > Hello,
> >
> > When building Libgcc with new porting gcc, _floatdidf.o failed for
> > undefined symbol
> > _floatsidf. I've been told that _floatsidf is in fpbit.c as
> > _si_to_df.o. Then I mod
On Thu, Sep 15, 2005 at 04:45:11PM -0700, Fariborz Jahanian wrote:
> But
> a more general question is should we always set the flags for
> symbol_ref whenever such a node is created for a declared symbol?
Whenever it's created for real, yes. In this case we're just guessing
at costs, so it ou
Over the past few months, I've been working on porting to IA32 and
AMD64/EM64T the interesting bits of the TLS design I came up with for
FR-V, achieving some impressive speedups along with slight code size
reductions in the most common cases.
Although the design is not set in stone yet, it's fully
Mark, in PR c++/11987 you added a comment saying that it was a
regression. But the more I look at it, the less I understand it.
The test case is:
==
template struct X {
struct I { I(); };
};
template struct Y : X {
typedef typename
... just a quickie here... I just noticed that I don't see the fortran
test results on cvs trunk anymore... I suppose this might be related
to the change of name from f95/gfortran to fortran...
--
Cheers,
/ChJ
33 matches
Mail list logo
