Just a nit: 5 years ago that was true. Now \n is "native"
Was that part of the OS/X migration, or otherwise? Just curious.
Part of the migration. OS X /is/ unix. Ok, I'm sure that's an
inaccurate statement and I trust the more experienced Apple guys here
will gently correct me. But
Hello,
I have a doubt here about define_expand and would be appreciated for
your any help. The internals say,
Usually these statements prepare temporary registers for use as
internal operands in the RTL template, but they can also generate RTL
insns directly by calling routines such as emit_insn,
Hey,
It's very sorry. I have just found the answer just in the context.
It's a so stupid question.
DONE
Use the DONE macro to end RTL generation for the pattern. The only RTL
insns resulting from the pattern on this occasion will be those
already emitted by explicit calls to emit_insn within the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Oct 26, 2005 at 02:22:55AM -0700, Kean Johnston wrote:
> If you're working in an ISO9000 environment where every single source
> line change is tracked by a rather burdensome process, the last thing
> you want to do is invoke that process for s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Oct 26, 2005 at 03:43:15PM -0700, Eric Christopher wrote:
> >Don't you think it is reasonable to fix horrible coding errors like
> >this, you are just asking for maintenance problems. In the short
> >term, kludging may make sense, in the long t
Bernd Jendrissek wrote:
My vote: I don't like surprises, and I'd like this code:
int x; // variable x \\
int y; // variable y \\
to do exactly the same as this code:
int x; // variable x \\
int y; // variable y \\
even if that behaviour is not the intent of the programm
On 2005-10-26, Eric Christopher <[EMAIL PROTECTED]> wrote:
> The problem is that it's portable to every other compiler we've
> tested. I am curious what icc and xlc do, but those are the only
> two not tested.
I've just checked icc and it follows the croud (i.e. it treats
"backslash space newline"
Are you guys done trying to decide what color to paint this bikeshed
yet? If not, I suggest maroon (http://maroon.bikeshed.com), or maybe
aquamarine (http://aquamarine.bikeshed.com).
I believe every opinion anyone could ever have about this issue has been
put forth, and nobody on either side has
Daniel Berlin wrote:
Which is invariably why it has generated so much discussion.
Surely everyone is familiar with Parkinson's second law (time
spent discussing an issue is inversely proportional to its
importance)
I believe every opinion anyone could ever have about this issue has been
put
Bernd Jendrissek wrote:
Also, if a sed script that modifies comments is too great a burden to
bear for such a beaurocracy, then using a different compiler should be
even more of a red-tape jungle. If it isn't, the management system is
broken and you might as well not bother with all those burden
Scott Robert Ladd wrote:
I'm not familiar-enough with ISO 9000 to judge whether a sed script is
"too great a burden", but I once worked in an environment where writing
a Python script to clean some ugly code got someone (not me) fired for
using an "unauthorized tool", even when the script prod
Scott Robert Ladd wrote:
Much as I agree with your sentiments, in many environments, the use of
ISO 9000 is *required*, as in you don't get the contract if you don't
follow ISO 9000.
Actually this is not so common, we have very rarely run into this
requirment. CMM model level is a much more
Much as I agree with your sentiments, in many environments, the use of
ISO 9000 is *required*, as in you don't get the contract if you don't
follow ISO 9000. I have not seen any evidence, personally, that ISO 9000
actually ensures a perfect product, but it is a political requirem
> > I believe every opinion anyone could ever have about this issue has been
> > put forth, and nobody on either side has been convinced of anything,
> > other than that the other side just doesn't get it.
>
> Well the purpose of the discussion here is precisely to see
> if there is a consensus f
Hi
I have following problem
When I compile c source file with options:
mips64-linux-gnu-gcc -c -mabi=64 -march=rm9000 -gdwarf-2
and then when I use dwarfdump the value of atribute dw_at_high_pc is 0 that is
surely wrong value
could you help me please to solve this problem (if I have t
On Thu, 2005-10-27 at 16:06 +0200, Ladislav Lestan wrote:
> Hi
> I have following problem
> When I compile c source file with options:
>
> mips64-linux-gnu-gcc -c -mabi=64 -march=rm9000 -gdwarf-2
>
> and then when I use dwarfdump the value of atribute dw_at_high_pc is 0 that
> is surely wrong
Robert Dewar wrote:
It sounds like you are not familiar with ISO 9000 at all :-)
This standard is about following your internal rules, it is not
a set of rules itself, so if you have a rule which prohibits SED
scripts in your environment, this is a rule you have created
for yourself, and you can
So I assume it is possible for an ISO 9000 environment to allow for ad
hoc sed scripts to fix trivial problems, and it would be the specific
institution, and not ISO 9000, that is broken (IMHO) if anal rule
prevented such utilitarian acts?
The question is what does "ad hoc" mean?
> So I assume it is possible for an ISO 9000 environment to allow for
> ad hoc sed scripts to fix trivial problems, and it would be the
> specific institution, and not ISO 9000, that is broken (IMHO) if
> any rule prevented such utilitarian acts?
When one of my previous employers went ISO9000, it
Scott Robert Ladd wrote:
Ah! I worked in only one place, a defense contractor, where ISO 9000 was
"followed", and the way management talked, their procedures were
dictated by ISO 9000. So I gather my one experience gave me an
inaccurate view of the subject?
The only sense in which the proc
Daniel Berlin wrote:
I'm sorry, did it require 200 emails for people to figure this out?
I'd think that we could have stopped at 10, maybe less.
Instead, everybody just has to throw their opinion on whitespace in,
without bothering to notice someone put forth that opinion 5 minutes
ago.
Not o
On Oct 27, 2005, Robert Dewar <[EMAIL PROTECTED]> wrote:
> When you step out of customs at the Bangkok airport, you see a big
> booth saying "ISO 9000 compliant taxi service" :-)
``Sorry, sir, can't drive you $there, my procedure says I can only take
passengers $elsewhere. I'm afraid the driver
Hello
Please your's advice.I think such a problem with newlib...or with my gcc
powerpc building process or with the makefile I attach a Zip example.
Please your remarks to the following procedure
A. Under Cygwin - XP SP2 machine
Getting the following tar files than extract / cerate the
Daniel Berlin wrote:
I believe every opinion anyone could ever have about this issue has been
put forth, and nobody on either side has been convinced of anything,
other than that the other side just doesn't get it.
Well the purpose of the discussion here is precisely to see
if there is a conse
DJ Delorie <[EMAIL PROTECTED]> writes:
>> i heard that gcc is also a cross-compiler, so i want to get know if
>> it can be used as an M16C compiler?
>
> Yes. The target you want to use to build gcc et al is "m32c-elf".
>
> To compile for the m16c specifically, use "m32c-elf-gcc -mcpu=m16c ..."
t
> > To compile for the m16c specifically, use "m32c-elf-gcc -mcpu=m16c ..."
>
> thanks. is that a 4.02 option? i can not find them on my 3.4 gcc man page.
The r8c/m16c/m32c port is new. Currently, it's only in the mainline
CVS sources, and will be "officially" released in the gcc 4.1 series.
>
Hi,
We have run into an excess precision problem on IA-64, similar to the infamous
problem on IA-32. A C testcase is attached.
[EMAIL PROTECTED]:~/EA26-004> gcc -v
Using built-in specs.
Target: ia64-sgi-linux-gnu
Configured with: /home01/botcazou/cvs/gcc/configure ia64-sgi-linux-gnu
--prefix=/
>
> --Boundary-00=_dFRYDl9RKCduOdb
> Content-Type: text/plain;
> charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> Hi,
>
> We have run into an excess precision problem on IA-64, similar to the
> infamous
> problem on IA-32. A C testcase is attached.
>
>
> This seems like any other target which has a fused multiply and add
> instruction like PPC. Maybe a target option to turn on and off the fma
> instruction like there is for PPC.
I'm under the impression that it's worse on IA-64 because of the "infinite
precision", but I might be wrong.
--
E
Dorit wrote:
It looks like maybe a 64bit scalar-evolution issue - when I compile on
powerpc-linux with -m64, I also get the
"vect4.f:4: note: not consecutive access"
message.
This problem looks very similar to PR18403 which has been resolved a
while
Daniel was right in that the discussion has degenerated. So, here's
a concrete proposal. Think of it as a start on a documentation patch.
Since there is no consensus, it seems that the right solution is to
have options. I think that the following concept can solve the problems.
-fno-eol-whites
> -Wcontinued-cpp-comment
>
> Warn if there is a C++-style comment that is continued by a backslash at
> the end of the line, and the following line contains something other
> than whitespace and comments. The current setting of
> -f{no-}eol-whitespace-strip is used to decide what is a co
I'm good with this proposal. I was against the flag in the first
place for a desire to pick something and let's do that, but it seems
like with so much furor over it we should probably just have a flag. :)
-eric
On Oct 27, 2005, at 14:12, Eric Botcazou wrote:
I'm under the impression that it's worse on IA-64 because of the
"infinite
precision", but I might be wrong.
Fused multiply-add always uses "infinite precision" in the intermediate
result. Only a single rounding is performed at the end. We real
I wrote:
I'm now going to try to compile HIRLAM with 32 bit pointers.
And ... here are the results:
With 64-bit pointers: 2685 out of 9799 loops vectorized.
With 32-bit pointers: 3269 out of 8854 loops vectorized.
Why there are more loops in the 64-bit case is beyond my understanding -
> Fused multiply-add always uses "infinite precision" in the intermediate
> result. Only a single rounding is performed at the end.
Of course, but I was implicitly referring to the 82-bit thing. But it seems I
was wrong, as the testcase fails on PowerPC w/ -mfused-madd too.
--
Eric Botcazou
So I assume it is possible for an ISO 9000 environment to allow for ad
hoc sed scripts to fix trivial problems, and it would be the specific
institution, and not ISO 9000, that is broken (IMHO) if anal rule
prevented such utilitarian acts?
ISO9000 is a pretty broad word these days. As someone
moshed (sent by Nabble.com) wrote:
/ usr/local/bin/../powerpc-eabi/lib/libc.a(vfprintf.o)(.text+0x18a0): In
function `_vfprintf_r':
.../../../.././newlib/libc/stdio/vfprintf.c:1065: undefined reference to
`__umoddi3'
These are in the libgcc library.
/usr/local/bin/../powerpc-eabi/lib/libc.a
Hi,
We have run into an exception propagation problem on IA-64/Linux. An
admittedly contrived C++ testcase is attached.
[EMAIL PROTECTED]:~/EA27-007> g++ -v
Using built-in specs.
Target: ia64-sgi-linux-gnu
Configured with: /home01/botcazou/cvs/gcc/configure ia64-sgi-linux-gnu
--prefix=/nile.bu
It says it is *recommended* that $HOME/.ssh/config have permission 600.
However, I seem to get an error if it doesn't, so I think this should be
"required", not "recommended".
On Thursday 27 October 2005 21:22, Richard Kenner wrote:
> It says it is *recommended* that $HOME/.ssh/config have permission 600.
> However, I seem to get an error if it doesn't, so I think this should be
> "required", not "recommended".
There's also a reason why it's a wiki.
Paul
On Thu, Oct 27, 2005 at 10:21:08PM +0200, Eric Botcazou wrote:
> We have run into an exception propagation problem on IA-64/Linux. An
> admittedly contrived C++ testcase is attached.
I'm not sure that the C++ testcase is in fact valid. A lawyer would
have to actually weigh in on that claim.
>
> > -Wcontinued-cpp-comment
> >
> > Warn if there is a C++-style comment that is continued by a backslash at
> > the end of the line, and the following line contains something other
> > than whitespace and comments. The current setting of
> > -f{no-}eol-whitespace-strip is used to decide
On Oct 27, 2005, at 12:06 AM, Paolo Bonzini wrote:
Unfortunately, GUI programs such as TextEdit seem not to know this,
Odd, I just created a file and saved it:
mrs $ od -c -x ~/Desktop/barfoo.c
000m i k e \n w a s \n h e r e \n
6d696b650a77
> I'm not sure that the C++ testcase is in fact valid. A lawyer would
> have to actually weigh in on that claim.
OK. But we have valid Ada testcases exhibiting the problem.
> Try again on ia32 with -fpic. That should go through
> dw2_force_const_mem just the same.
Right, but the problem doesn
Geert Bosch <[EMAIL PROTECTED]> writes:
> On Oct 27, 2005, at 14:12, Eric Botcazou wrote:
>> I'm under the impression that it's worse on IA-64 because of the
>> "infinite
>> precision", but I might be wrong.
>
> Fused multiply-add always uses "infinite precision" in the intermediate
> result. Only
> > This seems like any other target which has a fused multiply and add
> > instruction like PPC. Maybe a target option to turn on and off the fma
> > instruction like there is for PPC.
>
> I'm under the impression that it's worse on IA-64 because of the "infinite
> precision", but I might be w
http://www.thedailywtf.com/forums/48364/ShowPost.aspx
I wonder if one day, gcc will be able to use -Ostupidity to simplify such
thingies ;)
For those who did not noticed yet, I am just trying to take the piss here.
Thanks ;)
--
Vercetti
> The HP compiler generates fused multiply and add by default and has several
> settings for the +Ofltacc option to control this (and other optimizations
> that affect floating point accuracy).
>
> +Ofltacc=default
>
> Allows contractions, such as fused multiply-add (FMA), but
> disallo
Is there a plan to support anonymous svn access via http?
The possibility was mentioned in
http://gcc.gnu.org/ml/gcc/2005-02/msg00618.html
The svn: protocol won't work through our corporate firewall.
On Thu, Oct 27, 2005 at 11:10:10PM +0200, Eric Botcazou wrote:
> > Try again on ia32 with -fpic. That should go through
> > dw2_force_const_mem just the same.
>
> Right, but the problem doesn't trigger, probably because of the relative
> encoding:
>
> .LLSDACSE3:
> .byte 0x1
>
http://gcc.gnu.org/wiki/SvnSetup has the following example for
checking out the GCC sources under "Checking out a tree"
svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
but this doesn't work for me. Rather, I'm getting:
% svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
Permission denied (publickey
Hi,
I am trying to understand alias analysis. And currently using
gcc 4.0 I find that it reports a pointer crossing procedure
boundaries as pointing to anything even in the simplest case of a
passsing by reference. I guess interproceural analysis is hard in
general but is it so even in t
> http://gcc.gnu.org/wiki/SvnSetup has the following example for
> checking out the GCC sources under "Checking out a tree"
>
> svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
>
> but this doesn't work for me. Rather, I'm getting:
>
> % svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
> Permission
Joe Buck <[EMAIL PROTECTED]> writes:
| > > -Wcontinued-cpp-comment
| > >
| > > Warn if there is a C++-style comment that is continued by a backslash at
| > > the end of the line, and the following line contains something other
| > > than whitespace and comments. The current setting of
| >
Or at least I think it's the head. I am still learning subversion. :)
I am testing using gcc-head-test with the *-rtems targets. I managed
to build a native compiler and am using that to build the cross
compilers. But when the build gets around to trying to build newlib, it
is using CC=${ta
>
>
> Or at least I think it's the head. I am still learning subversion. :)
The SVN version of the head that is live right now is still a couple
weeks old. So any troubles you have right now might just be due to
that. You can try cvs which is in a read only state (for the rest of
its life).
On Thu, 27 Oct 2005, Joe Buck wrote:
Is there a plan to support anonymous svn access via http?
It can be slower and more resource intensive.
I'd like to avoid it if possible, but if not,
When I do it, it looks like after I log out, something is still running. Is
there something I have to stop?
Tobias Schlüter <[EMAIL PROTECTED]> wrote:
>> http://gcc.gnu.org/wiki/SvnSetup has the following example for
>> checking out the GCC sources under "Checking out a tree"
>>
>> svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk
>>
>> but this doesn't work for me. Rather, I'm getting:
>>
>> % svn co svn
On Oct 27, 2005, at 17:19, Andreas Schwab wrote:
I think this is what the FP_CONTRACT pragma is supposed to provide.
Yes, but it seems there is no way in the middle end / back end to
express this. Or am I just hopelessly behind the times? :)
-Geert
Mike Stump <[EMAIL PROTECTED]> wrote:
>> Uhm, I'm not sure how to explain this without being too pedantic.
>> Does this
>> sound clearer?
>
> This tool tracks each individual change (fine-grained) and will never
> reapply an already applied change.
>
> I think that is a high level answer, and comp
> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
Gerald> This is fine to use, but our configure/build system really should
Gerald> be clever enough to automatically set pkgdatadir to the correct
Gerald> value in the first place: $(prefix)/libdata/pkgconfig on FreeBSD,
Gerald> and $(lib
On Thursday 27 October 2005 18:37, shreyas krishnan wrote:
> I find that it reports a pointer crossing procedure
> boundaries as pointing to anything even in the simplest case of a
> passsing by reference.
Yes, that's one of the basic limitations in 4.0. Several of these
limitations are goi
On Oct 27, 2005, at 17:25, Steve Ellcey wrote:
It would be easy enough to add an option that turned off the use of
the
fused multiply and add in GCC but I would hate to see its use
turned off
by default.
Code that cares should be able to express barriers across which no
contraction is poss
> The name here would seem to imply that we *are* mangling the type
> name: "typeinfo for foo()::S". Which begs the question of why you're
> seeing something different for ia64.
Both names are mangled identically (either on IA-32 or IA-64) because they are
supposed to be local to the translation
Hi,
I don't seem to be able to access svn:
# svn ls svn://gcc.gnu.org/svn/gcc
[several (2-3) minutes pass, during which svn is non-interruptable]
svn: Can't connect to host 'gcc.gnu.org': Connection timed out
Ralf
Eric Botcazou wrote:
>>The name here would seem to imply that we *are* mangling the type
>>name: "typeinfo for foo()::S". Which begs the question of why you're
>>seeing something different for ia64.
>
>
> Both names are mangled identically (either on IA-32 or IA-64) because they
> are
> suppos
Joe Buck wrote:
> So the amended suggestion is to fix -Wcomment to shut up about continued
> comments that don't matter, and also to add the new -f option to switch
> the handling of spaces-at-the-end.
I think your proposal, as amended, is the right approach.
I generally don't much like new comm
> This test case is valid, and the results observed are in incorrect; in
> other words, yes, there is a bug.
Thanks for confirming.
> In general, comparison of type_info objects is supposed to be done by
> checking for address equality of the type info strings. On systems
> without weak symbols,
Ralf Corsepius <[EMAIL PROTECTED]> writes:
> Hi,
>
> I don't seem to be able to access svn:
>
> # svn ls svn://gcc.gnu.org/svn/gcc
> [several (2-3) minutes pass, during which svn is non-interruptable]
> svn: Can't connect to host 'gcc.gnu.org': Connection timed out
I didn't read that it's up agai
On Fri, 2005-10-28 at 08:49 +0200, Andreas Jaeger wrote:
> Ralf Corsepius <[EMAIL PROTECTED]> writes:
>
> > Hi,
> >
> > I don't seem to be able to access svn:
> >
> > # svn ls svn://gcc.gnu.org/svn/gcc
> > [several (2-3) minutes pass, during which svn is non-interruptable]
> > svn: Can't connect t
72 matches
Mail list logo
