I have a bit of a disagreement with the optimization toward memset()
calls. In one of my libraries, libteklti, I have a function named
ucharempty(), which frees a uchar_t (unique character structure) from
memory. If the user elects to have the memory erased prior to calling
free(), memset() is s
Most of this really doesn't deserve an answerr, but I'll give you a
couple anyway. You spend a lot of time blaming people for their
opinions, without any evidence that you've actually understood their
opinions right. Most of what I've snipped is completely untrue.
On Fri, Aug 26, 2005 at 10:59:5
A common situation would be:
if (condition) {
flag = 1
msg = "Hello World";
} else
flag = 0; [1]
...
if (flag)
printf ("I say, %s\n", msg); [2]
Point [1] is where I "fail" to in
DJ Delorie wrote:
However, I have a counter-proposal, which is that we use libiberty's
existing buildargv.
I wasn't specifying DJGPP's exact code, mostly these features:
OK.
1. Recursion. @file inside another @file causes further expansion.
Yes, my implementation happened to already do
Kean Johnston wrote:
> Hello everyone,
>
> There is a warning message I would dearly love to see improved
> a little. Its the one where you use a variable without it being
> initialized first:
>
> foo.c:123: warning: `foo' might be used unitialized in this function
>
> Obviously, there was som
Hello everyone,
There is a warning message I would dearly love to see improved
a little. Its the one where you use a variable without it being
initialized first:
foo.c:123: warning: `foo' might be used unitialized in this function
Obviously, there was some code somewhere that used variable
`f
> However, I have a counter-proposal, which is that we use libiberty's
> existing buildargv.
I wasn't specifying DJGPP's exact code, mostly these features:
1. Recursion. @file inside another @file causes further expansion.
2. Support for "find -print0" which is more robust than
whitespace-d
DJ Delorie wrote:
However, I don't see a way to do that for *all* OSs, and people seem
to want that. So while I won't actively support it in libiberty, I
won't hinder it either.
Great!
To make it as unobtrusive as possible, I request that the
application-side only require one line:
DJ Delorie <[EMAIL PROTECTED]> writes:
>> gcc -c ./@foop.cpp
>>
>> and of course the same goes for files with names that begin with '-'.
> That only works if the argument reflects a file name, and not some other
> syntactical sugar. Granted, gcc has no such arguments, but libiberty
> has a wide
On 26 Aug 2005, Kai Ruottu complained:
>Not even mentioning Linux and its GCC idea: "There can
> be only one!", seemingly borrowed from the "Highlander" -- that all the
> GCCs on a host system should use a common $prefix has seemingly been
> totally unknown by the Linux people and t
On Fri, Aug 26, 2005 at 05:03:08PM +0100, Joern RENNECKE wrote:
> On the other hand, tree.c uses char_type_node as the type of the
> smallest addressable
> unit:
>
> tree.c:489 make_node_stat
>case tcc_type:
> TYPE_UID (t) = next_type_uid++;
> TYPE_ALIGN (t) = char_type_node ? TYPE_
Tristan Wibberley wrote:
I certainly agree with (a). For (b), I think a gcc compiler that is
intended to produce normal Windows binaries should have the same
commandline interface as Microsoft's compiler (I mean *all* of the
commandline interface) - for build scripts and development environments
Mark Mitchell wrote:
> Tristan Wibberley wrote:
>
>> Mark Mitchell wrote:
>>
>>
>>
>>> However, there's demonstrable interest in this feature for GNU/Linux as
>>> well, from the lists, and for Java on all operating systems.
>>>
>>
>>
>> Please don't use '@filename' on Linux, use a normal switch wi
On Fri, 2005-08-26 at 01:46, Etienne Lorrain wrote:
> Shall I create a new bug report or re-open:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21626
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
That's a different bug, in the gimplifier. This one is in the
middle-end in expand_expr. I'd
On Fri, 2005-08-26 at 10:21 -0700, Ian Lance Taylor wrote:
> Sergei Organov <[EMAIL PROTECTED]> writes:
>
> > Anyway, my gcc docs only mention:
> >
> > --target-help
> > --help
> > --version
> > --param NAME=VALUE
>
> Yeah, it looks like the double dash long options got added without
> ever bein
Sergei Organov <[EMAIL PROTECTED]> writes:
> Anyway, my gcc docs only mention:
>
> --target-help
> --help
> --version
> --param NAME=VALUE
Yeah, it looks like the double dash long options got added without
ever being documented.
For the record, they were added here:
Sat Mar 6 15:08:59 1993 R
Ian Lance Taylor writes:
> Sergei Organov <[EMAIL PROTECTED]> writes:
>
> > Laurent GUERBY <[EMAIL PROTECTED]> writes:
> > > If we add a library function to handle this we might want to
> > > add a GNU-style argument equivalent like
> > >
> > > gcc --arguments-from-file=file
> >
> > AFAIK gcc
Original Message
>From: Mike Stump
>Sent: 26 August 2005 17:48
> On Friday, August 26, 2005, at 12:59 AM, Kai Ruottu wrote:
>> Is there any sane reasons for this on systems which never have had that
>> non-GNU native 'cc' ?
>
> Consistency. This is only bad if one abhors consistency and
Sergei Organov <[EMAIL PROTECTED]> writes:
> Laurent GUERBY <[EMAIL PROTECTED]> writes:
> > If we add a library function to handle this we might want to
> > add a GNU-style argument equivalent like
> >
> > gcc --arguments-from-file=file
>
> AFAIK gcc doesn't support any GNU-style arguments, isn'
On Friday, August 26, 2005, at 12:59 AM, Kai Ruottu wrote:
Is there any sane reasons for this on systems which never have had that
non-GNU native 'cc' ?
Consistency. This is only bad if one abhors consistency and
predicability. No?
I'll abstain from answering the other questions, I think
Joern RENNECKE wrote:
java uses char_type_node for its character type, which is 16 bits.
gcc/java/decl.c:747 java_init_decl_processing:
TYPE_PRECISION (char_type_node) = 16;
On the other hand, tree.c uses char_type_node as the type of the
smallest addressable
unit:
tree.c:489 make_node_st
Joern Rennecke wrote:
I've started a make check-target-libjava yesterday, in the hope that
this would give
me a handle on things, but it's still not finished after 22 hours.
It's still not finished, but in the meantime I modifed the code to abort
in the case where
the old code would redu
Laurent GUERBY <[EMAIL PROTECTED]> writes:
> If we add a library function to handle this we might want to
> add a GNU-style argument equivalent like
>
> gcc --arguments-from-file=file
AFAIK gcc doesn't support any GNU-style arguments, isn't it?
I'd consider
gcc @file
gcc -@ file
gcc -args-from-
On Aug 26, 2005, at 10:16 AM, Helge Hess wrote:
Hi,
I'm experiencing some issue with using a precompiled header with an
Objective-C file. When including the header, I'll get duplicate
symbols, like this:
---snip---
SaxAttributeList.m:188: error: redefinition of 'struct _objc_symtab'
SaxAttr
Hi,
I'm experiencing some issue with using a precompiled header with an
Objective-C file. When including the header, I'll get duplicate
symbols, like this:
---snip---
SaxAttributeList.m:188: error: redefinition of 'struct _objc_symtab'
SaxAttributeList.m:188: error: redefinition of 'struct _ob
> Unless the @file contains a file that begins with a '\@' that got passed
> on to gcc, presumably. I guess that would mean that you'd need to do
> some complicated quoting to actually pass a file beginning with '@' to
> gcc.
That's why DJGPP silently ignores @files that don't correspond to
file
Snapshot gcc-4.1-20050826 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050826/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-08-26 10:43 UTC
You'll
Original Message
>From: Daniel Towner
>Sent: 26 August 2005 11:48
> Hi all,
>
> I am hoping to contribute a new port to gcc in the near future and I am
> currently testing the port using the testsuite. My new port is for a
> 16-bit embedded processor which doesn't support any conventional
Hi all,
I am hoping to contribute a new port to gcc in the near future and I am
currently testing the port using the testsuite. My new port is for a
16-bit embedded processor which doesn't support any conventional IO
(printf, etc.), nor does it support floating point. Is there an easy way
to
If we add a library function to handle this we might want to
add a GNU-style argument equivalent like
gcc --arguments-from-file=file
Which would be equivalent to:
gcc @file
May be some GNU tools already have standardized on a long
argument name for such a feature, but none came to my mind
(and
Ivan Novick wrote:
> Can you recommend a solution for compiling Windows DLLs on any
> variation of UNIX?
You can use GCC/MinGW built as a cross-compiler to do this. If you
do not mind a shameless plug, read:
http://ranjitmathew.hostingzero.com/phartz/gcj/bldgcj.html
HTH,
Ranjit.
--
Ranjit
Thanks James,
Shall I create a new bug report or re-open:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21626
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21478
Etienne.
--- James E Wilson <[EMAIL PROTECTED]> wrote:
> Etienne Lorrain wrote:
> > Investigated again a big increase of size goin
Mike Stump wrote:
configure --with-headers=/cygwin/usr/include --with-libs=/cygwin/usr/
lib target=i386-pc-cygwin && make && make install
would be an example of how I used to build one up, see the gcc
documentation for details. --with-sysroot or some such might be
another way to to do it
33 matches
Mail list logo
