Re: Cross Compiler Unix - Windows

[Kai Ruottu]

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 now-a-days.


 That the 'native' Cygwin GCC mimics some unexisting proprietary native
'cc' in its headers and libraries directories instead of just being only
another "C/C++/Java/Fortran/..." compiler set on Windoze, like those
GCCs for 'h8300-*', 'sh-*, 'arm-*' etc. GCCs without any GCCs on their
'native' area, has always been very weird... The same thing happens with
the 'official' MinGW GCC, it too tries to mimic some still unknown
native 'cc' !  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 they really expected the native
GCC to be the only GCC ever on that host! Or that if one needs more
GCCs, they can only be other versions for the native GCC...

 Platforms like Solarises, AIXes, HP-UXes, Irixes, SVR[3-5],... really
have their proprietary native 'cc's which GCC has some sane reasons to
mimic and so try to access their installed headers and libraries from
their original places. But the native-GCC will be installed into some
'local' or 'options' place, '/usr/local', '/opt/gcc' or something, where
one can add as many other GCCs as one wishes. Not to the '/usr' as has
been the rule on those "no native 'cc' seen ever here" platforms. Is
there any sane reasons for this on systems which never have had that
non-GNU native 'cc' ?

 The '--with-sysroot' tries to keep the 'proprietary' layouts even on
the cross-hosts, where people could always use the "standard install
layout for GCC", every GCC installed using just the same rules. So the
situation where all crosscompilers use their own proprietary layouts
has somehow been seen being better that trying to standardize the GCC
installation layout.

 The current cross-GCC install layout has its problems : there is only
one $target dependent place for the libraries when a typical native GCC
has at least two, '/lib' and '/usr/lib'. Meanwhile a cross-GCC has two
places for the headers: the '$tooldir/include' for the standard (posix)
headers and the '$tooldir/sys-include' for the system-specific
(non-posix etc.) headers. And maybe the last 10 years or so the GCC
developers have mixed these apples and oranges, standard and system
things, so the cross-GCC build has been a continuous mess, target
headers being searched from the 'sys-include' when the de-facto place
is the 'include' (For instance the newlib install puts the target 
headers to the 'include' and they are there when one wants to try to

build a newer GCC.) And such... If most of the native GCCs have only
the '/usr/include', the STANDARD_INCLUDE_DIR, and there is no place for
the SYSTEM_INCLUDE_DIR (please search the GCC manuals for this), is it
so hard to leave the 'sys-include' unnoticed?

 However anyone who has built more than 10 GCCs for more than 10 targets
and then installed them on the same development platform, has somehow
got used to the current (but limiting) layout, and has solved the
problems somehow. For instance what to do with the Solaris2 '/usr/lib',
'/usr/ccs/lib', '/usr/ucblib', '/usr/ccs/ucblib' and so on library
places someone recently had some problems with. And before the
'--with-sysroot' appeared at all...

 Before trying to move the proprietary layouts into the peaceful?
land of cross, it could have been better to ask the crosscompiler
builders how they have solved these "copy the target headers and
libs from the native system and put them to work with the cross-GCCs
too" problems. Maybe then there had no reason for the '--with-sysroot'.
Does it even work as one would expect it to work, solving those '/lib'
and '/usr/lib' in the 'libc.so' script problems and so on?

 Ok, as long as there are those stupid installs to '/usr' on the native
front, as long people must think how on earth the natively installed
C libraries can be copied to the cross host. Linux is a good example
about this stupidity in the very beginning. Instead of thinking how
one could produce apps for Linux easily on ANY host, it was thought
how one could produce apps for Linux ONLY on the Linux host and so
trying to make cross-compiling to Linux as hard as possible.

 Not using '--with-sysroot=' at all, but simply putting the '/lib' and
'/usr' stuff below a '$sysroot' and then symlinking the 
'$sysroot/usr/include' and '$sysroot/usr/lib' to be seen as 'include'

and 'lib' on the $gcc_tooldir, adding a couple more symlinks to the
'lib' and editing the absolute paths away from the 'libc.so', enables
one to get a Linux-targeted GCC to work. With 64-bit bi-arch targets
one of course uses the default 'lib64' as the place here the
$gcc_tooldir/li

Re: ia32: clearing a 7116 bytes struct inserted as "C.171.8759: .zero 7116 ... memcpy()" with gcc-4.0.2

[Etienne Lorrain]

  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 going from GCC-3.4 to 4.x
> >  (gcc (GCC) 4.0.2 20050811 (prerelease)) on my Gujin-v1.2, quickly way
> >  to reproduce:
> 
> If you want this fixed, you should file a bug report into our bugzilla
> database.
> 
> Here is a quicker way to reproduce the problem.
> int
> sub (int i)
> {
>   int array[100] = { 0 };
> 
>   sub2 (&array[i]);
> }
> 
> We are dumping the constructor to memory, and then doing a memcpy, when
> it would be much better to just do a memset.
> 
> The culprit is code in expand_expr_real_1, case CONSTRUCTOR, which
> checks to see if we have a constructor of all constants, in which case
> we force it to the constant pool.  Not a good idea if the constructor is
> a megabyte in size, and all of the elements are constant zero.  I don't
> have a handy gcc-3.4.3 build tree, but it is apparently a VECTOR_TYPE
> check that prevents this code from triggering there.
> -- 
> Jim Wilson, GNU Tools Support, http://www.specifix.com
> 







___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com

Re: Cross Compiler Unix - Windows

[Ranjit Mathew]

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 Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

Re: 4.2 Project: "@file" support

[Laurent GUERBY]

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 I'm not that proud of my proposed name :).

Laurent

PS: removed gcc-patches

How do I disable classes of test?

[Daniel Towner]

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 disable all floating point tests, and all IO tests in the testsuite, 
other than adding suitable target directives in each file?


thanks,

dan.


Daniel Towner
picoChip Designs Ltd., Riverside Buildings, 108, Walcot Street, BATH,
BA1 5BG
[EMAIL PROTECTED]
07786 702589 

RE: How do I disable classes of test?

[Dave Korn]

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 IO
> (printf, etc.), nor does it support floating point. Is there an easy way
> to disable all floating point tests, and all IO tests in the testsuite,
> other than adding suitable target directives in each file?
> 
> thanks,
> 
> dan.
> 


  Yep.  The attached patch shows how to extend the testsuite to add a whole
load of useful test-enable/disable-per-feature functionality.  After
applying this patch, you could add a line reading

set_board_info no_floating_point 0

to your board.exp and any testfile that contains the words 'float' or
'double' will be skipped.  It's just a crude line-based substring match, so
there will be false positives.  The patch is against 3.3.3, but should be
easily ported to newer or older versions, within reason.  It could be
reworked to allow cleverer regex searching if desired, but I didn't want to
make it overly slow.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today


testlib-improvements.diff
Description: Binary data

gcc-4.1-20050826 is now available

[gccadmin]

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 find:

gcc-4.1-20050826.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20050826.tar.bz2 C front end and core compiler

gcc-ada-4.1-20050826.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20050826.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20050826.tar.bz2  C++ front end and runtime

gcc-java-4.1-20050826.tar.bz2 Java front end and runtime

gcc-objc-4.1-20050826.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20050826.tar.bz2The GCC testsuite

Diffs from 4.1-20050819 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: 4.2 Project: "@file" support

[DJ Delorie]

> 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
files.  If you have some file @123.txt but don't have file 123.txt,
pass "@123.txt" to the program and it sees "@123.txt" in argv[].

The only time it's a problem is if you hae both @123.txt and 123.txt
as real files, then you can't pass "@123.txt" to argv[] without
quoting it (./@123.txt).

PCH / ObjC issue with gcc 4.0.2-pre

[Helge Hess]

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 _objc_module'
SaxAttributeList.m:188: error: redefinition of '__objc_gnu_init'
common.h:26: error: previous definition of '__objc_gnu_init' was here
{standard input}: Assembler messages:
{standard input}:2136: Error: symbol `_OBJC_SYMBOLS' is already defined
---snap---

The same makefile/compilation flags work just fine on OSX 10.4.2.

More logs:
---snip---
[EMAIL PROTECTED]:~/dev/SOPE-4.5/sope-xml/SaxObjC$ gcc --version
gcc (GCC) 4.0.2 20050816 (prerelease) (Debian 4.0.1-5)
[EMAIL PROTECTED]:~/dev/SOPE-4.5/sope-xml/SaxObjC$ make messages=yes
Making all for library libSaxObjC...
cd .; \
/home/helge/GNUstep/Library/Makefiles/mkinstalldirs ./shared_debug_obj; 
\

rm -f obj; \
ln -s ./shared_debug_obj obj
if ! test -d ./derived_src; then \
  /home/helge/GNUstep/Library/Makefiles/mkinstalldirs ./derived_src; \
fi
gcc -x objective-c-header common.h -c \
  -pipe -Wall -Wno-protocol -Wall -DCOMPILE_FOR_GSTEP_MAKE=1 
-DSOPE_MAJOR_VERSION=4 -DSOPE_MINOR_VERSION=5 
-DSOPE_SUBMINOR_VERSION=52 -Wno-protocol 
-I/home/helge/GNUstep/Library/Headers/libFoundation/ix86/linux-gnu/GNU 
-DGNUSTEP=1 -DWITH_GSTEP_MAKE=1 -DLIB_FOUNDATION_LIBRARY=1 
-DFD_WITH_GSMAKE=1 -DGNUSTEP=1 -DGNU_RUNTIME=1 -D_REENTRANT -fPIC -g 
-Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE 
-fno-strict-aliasing -fgnu-runtime -I.. -I. 
-I/home/helge/GNUstep/Library/Headers 
-I/home/helge/GNUstep//Library/Headers 
-I/home/helge/GNUstep/Library/Headers/libFoundation 
-I/home/helge/GNUstep//Library/Headers/libFoundation 
-I/home/helge/GNUstep//Library/Headers/libFoundation 
-I/home/helge/GNUstep/Library/Headers/libFoundation 
-I/home/helge/GNUstep/Library/Headers/libFoundation/./GNU 
-I/home/helge/GNUstep//Library/Headers/libFoundation/./GNU 
-I/home/helge/GNUstep//Library/Headers/libFoundation/./GNU 
-I/home/helge/GNUstep/Library/Headers/libFoundation/./GNU \

   -o derived_src/common.h.gch
gcc SaxAttributeList.m -c \
  -pipe -Wall -Wno-protocol -Wall -DCOMPILE_FOR_GSTEP_MAKE=1 
-DSOPE_MAJOR_VERSION=4 -DSOPE_MINOR_VERSION=5 
-DSOPE_SUBMINOR_VERSION=52 -Wno-protocol 
-I/home/helge/GNUstep/Library/Headers/libFoundation/ix86/linux-gnu/GNU 
-DGNUSTEP=1 -DWITH_GSTEP_MAKE=1 -DLIB_FOUNDATION_LIBRARY=1 
-DFD_WITH_GSMAKE=1 -DGNUSTEP=1 -DGNU_RUNTIME=1 -D_REENTRANT -fPIC -g 
-Wall -DDEBUG -fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE 
-fno-strict-aliasing -fgnu-runtime -I.. -I. 
-I/home/helge/GNUstep/Library/Headers 
-I/home/helge/GNUstep//Library/Headers 
-I/home/helge/GNUstep/Library/Headers/libFoundation 
-I/home/helge/GNUstep//Library/Headers/libFoundation 
-I/home/helge/GNUstep//Library/Headers/libFoundation 
-I/home/helge/GNUstep/Library/Headers/libFoundation 
-I/home/helge/GNUstep/Library/Headers/libFoundation/./GNU 
-I/home/helge/GNUstep//Library/Headers/libFoundation/./GNU 
-I/home/helge/GNUstep//Library/Headers/libFoundation/./GNU 
-I/home/helge/GNUstep/Library/Headers/libFoundation/./GNU \

  -include ./derived_src/common.h \
   -o shared_debug_obj/SaxAttributeList.o
SaxAttributeList.m:188: error: redefinition of 'struct _objc_symtab'
SaxAttributeList.m:188: error: redefinition of 'struct _objc_module'
SaxAttributeList.m:188: error: redefinition of '__objc_gnu_init'
common.h:26: error: previous definition of '__objc_gnu_init' was here
{standard input}: Assembler messages:
{standard input}:2136: Error: symbol `_OBJC_SYMBOLS' is already defined
{standard input}:2302: Error: symbol `_OBJC_MODULES' is already defined
{standard input}:2351: Error: symbol `_OBJC_CLASS_NAME_0' is already 
defined

...
[EMAIL PROTECTED]:~/dev/SOPE-4.5/sope-xml/SaxObjC$ file derived_src/common.h.gch
derived_src/common.h.gch: GCC precompiled header (version 012) for 
Objective C

---snap---

Any hints?

Thanks a lot,
  Helge
--
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

Re: PCH / ObjC issue with gcc 4.0.2-pre

[Andrew Pinski]

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'
SaxAttributeList.m:188: error: redefinition of 'struct _objc_module'
SaxAttributeList.m:188: error: redefinition of '__objc_gnu_init'
common.h:26: error: previous definition of '__objc_gnu_init' was here
{standard input}: Assembler messages:
{standard input}:2136: Error: symbol `_OBJC_SYMBOLS' is already defined
---snap---


Can you report a bug? See http://gcc.gnu.org/bugs.html for directions.
I will look into it.  It is most likely an issue with the decl rewrite
but I don't know until I get a testcase.

-- Pinski

Re: 4.2 Project: "@file" support

[Sergei Organov]

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-file file

-- 
Sergei.

Re: 206 GCC HEAD regressions, 196 new, with your patch on 2005-08-23T19:50:19Z.

[Joern RENNECKE]

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 reduce the alignment for !STRICT_ALIGNMENT targets.
This turned up something rather ugly indeed:

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_stat
   case tcc_type:
 TYPE_UID (t) = next_type_uid++;
 TYPE_ALIGN (t) = char_type_node ? TYPE_ALIGN (char_type_node) : 0;

java type layout (Was: Re: 206 GCC HEAD regressions, 196 new, with your patch on 2005-08-23T19:50:19Z.)

[Joern RENNECKE]

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_stat
   case tcc_type:
 TYPE_UID (t) = next_type_uid++;
 TYPE_ALIGN (t) = char_type_node ? TYPE_ALIGN (char_type_node) : 0;




Could someone with a bit more java experience than be verify how we lay out
structs, unions and arrays with a single bool member?  I suspect that 
even without

my patch, they might be 8 bits large, 16 bit aligned

Re: Cross Compiler Unix - Windows

[Mike Stump]

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 they are 
better as ponder points.

Re: 4.2 Project: "@file" support

[Ian Lance Taylor]

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't it?

Actually, it does, but they aren't widely documented.  For example,
you can use --language instead of -x, etc.

Ian

RE: Cross Compiler Unix - Windows

[Dave Korn]

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
> predicability.  No?
> 
> I'll abstain from answering the other questions, I think they are
> better as ponder points.

  I'll just add this observation:

>   What becomes to Cygwin and MinGW, the same attitude as followed with
> Linux, that "producing any apps for Windoze should happen only on
> Windoze, or that when one does it on some other host, it still should
> happen just like on Windoze!", is totally weird to me. 

  It seems weird to me too.  Especially considering that at least one of the
main cygwin developers builds everything on linux with a linux-x-windows
toolchain.  So perhaps you have misunderstood the situation with cygwin;
cross-development is certainly possible, and _intended_ to be possible.  It
certainly isn't any kind of policy to _deliberately_ make development only
possible on native hosts.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: 4.2 Project: "@file" support

[Sergei Organov]

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 doesn't support any GNU-style arguments, isn't it?
> 
> Actually, it does, but they aren't widely documented.  For example,
> you can use --language instead of -x, etc.

My bad, -- confused by all that long options using single dash, sorry.

Anyway, my gcc docs only mention:

--target-help
--help
--version
--param NAME=VALUE

-- 
Sergei.

Re: 4.2 Project: "@file" support

[Ian Lance Taylor]

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  Richard Stallman  ([EMAIL PROTECTED])

* gcc.c: Handle long options by translation to old-style ones.
(translate_options): New function.
(option_map): New table.

and the table has been kept more or less up to date ever since.

Ian

Re: 4.2 Project: "@file" support

[Laurent GUERBY]

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 being documented.
> 
> For the record, they were added here:
> 
> Sat Mar  6 15:08:59 1993  Richard Stallman  ([EMAIL PROTECTED])
> 
>   * gcc.c: Handle long options by translation to old-style ones.
>   (translate_options): New function.
>   (option_map): New table.
> 
> and the table has been kept more or less up to date ever since.

That's new news :). 

Anyway I was answering a proposal by D.J. to provide a library function
and my understanding was that it was intended to be used beyond GCC as a
portable way to implement file as argument list (even if a call has to
be added project by project), and in this GNU project context I believe
it makes sense to add a double dash long option for it even if GCC in
practice does not offer them.

Laurent

Re: ia32: clearing a 7116 bytes struct inserted as "C.171.8759: .zero 7116 ... memcpy()" with gcc-4.0.2

[James E Wilson]

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 suggest opening a new bug as this is a
different problem.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: 4.2 Project: "@file" support

[Tristan Wibberley]

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 with an
>> argument. The problems of '-' being used for switches is bad enough
>> without another valid filename character being overloaded. At least the
>> '-' problem is well understood and people can avoid using filenames
>> beginning with '-'.
> 
> 
> Again, I'm amenable to changes to the technical details.
> 
> The first step is agreeing that (a) the feature is beneficial, and (b)
> the mechanism for implementing it, such as whether it should be done in
> crt0 or in libiberty.  I think everyone's agreed on (a), but I don't
> think DJ and I are yet seeing eye-to-eye on (b).  Once we get past that,
> we can work out these details.

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
that expect to see Micrsoft's tools. If it also provides a gcc
commandline interface, it should look exectly like the *NIX gcc, and
long commandlines could be supported by *NIX style shells that use
CreateProcess wrappers such as exec to use IPC to pass the cmdline
(where libcrt handles it).

So if you use normal Windows tools to build, you can use the MS style
cmdline, and if you use ported GNU tools, you can use the GNU style
commandline (and both shell, make, etc. and compiler contain specific
support for long commandline via IPC).

More work, its true, but its also much nicer (IMHO).

My justification is that Windows programmers expect to use /F /OO:bar
and @argsfile commandline arguments from cmd, and Linux developers
working on Windows expect to use -f --oo=bar and --args=argsfile
commandline arguments from bash. So that is what they respectively ought
to be given. In the case of the GNU interface, it looks like the shell
and compiler are capable of long commandlines... use Microsoft
counterparts for either and you lose the facility and can fall back to
--args= or @. When GNU utilities are ported, libcrt and exec can
understand the long commandline method, when new programs are written
they can use an LGPL libWinGNU.dll that contains such functions as
LongCreateProcess (or link to a dll that contains its own CreateProcess
or something).

-- 
Tristan Wibberley

Opinions expressed are my own and do not necessarily coincide with those
of my employer, etc.

Re: 4.2 Project: "@file" support

[Scott Robert Ladd]

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
that expect to see Micrsoft's tools.


This isn;t that difficult to do now -- on Windows, I wrote a wrapper to 
mask the underlying compiler, so that tools expecting MSVC work 
transparently with Intel and GCC compilers. Emulating Microsoft exactly 
doesn't need to be part of GCC itself.


That said, I am a supported of the @file concept in GCC, since it has 
uses beyond simple MSVC compatibility.


..Scott

Re: 206 GCC HEAD regressions, 196 new, with your patch on 2005-08-23T19:50:19Z.

[Richard Henderson]

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_ALIGN (char_type_node) : 0;

Oh wow.  Whatever nonsense is that?  It does seem like we should 
be able to replace that with BITS_PER_UNIT unconditionally.


r~

Re: Cross Compiler Unix - Windows

[Nix]

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 they really expected the native
> GCC to be the only GCC ever on that host! Or that if one needs more
> GCCs, they can only be other versions for the native GCC...

This is nonsense. I have a dozen cross-compilers on this box, all
installed into /usr. They do not collide as long as you configure with
--enable-version-specific-runtime-libs and
--program-{prefix,suffix,transform-name} and make slight adjustments
after installation (ditch libiberty.a and some locale and manpage stuff
that doesn't get its name suitably adjusted).

There is nothing whatsoever special about the system compiler on Linux.
It's just a GCC configured with particular switches, that is all.

>   The '--with-sysroot' tries to keep the 'proprietary' layouts even on
> the cross-hosts, where people could always use the "standard install
> layout for GCC", every GCC installed using just the same rules. So the
> situation where all crosscompilers use their own proprietary layouts
> has somehow been seen being better that trying to standardize the GCC
> installation layout.

Er, GCC will always look in ${tooldir}/lib for libraries, ${tooldir)/bin
for binaries, and so on. (Your comments below indicate that you know this:
so what are you talking about here?)

>   The current cross-GCC install layout has its problems : there is only
> one $target dependent place for the libraries when a typical native GCC
> has at least two, '/lib' and '/usr/lib'.

If you are installing libgcc_s.so* into /lib, you'd better damned well
know what you're doing, as you'll be overwriting the distribution's
copy. Doing it automatically strikes me as a seriously bad idea: anyone
installing an old GCC in parallel with a new one would stand at risk of
wrecking every program on their system dynamically linked against
libgcc_s. (Those of us who don't use distributions generally have
installation-time scripts that can do the necessary by-hand mv.)

There were huge flamewars^W^Wintense debates about this when libgcc
was made into a shared library: look at the list archives.

>  Meanwhile a cross-GCC has two
> places for the headers: the '$tooldir/include' for the standard (posix)
> headers and the '$tooldir/sys-include' for the system-specific
> (non-posix etc.) headers.

Personally I've never quite seen the point of sys-lib and sys-include.
I just dump all the target libraries and headers into the target-
specific lib and include directories. :)

>   However anyone who has built more than 10 GCCs for more than 10 targets
> and then installed them on the same development platform, has somehow
> got used to the current (but limiting) layout, and has solved the
> problems somehow. For instance what to do with the Solaris2 '/usr/lib',
> '/usr/ccs/lib', '/usr/ucblib', '/usr/ccs/ucblib' and so on library
> places someone recently had some problems with.

I created ${tooldir}/ccs/lib et al and just had a site-config script
construct suitable -L arguments to GCC. (If you're doing much
cross-compilation you'll end up with a site-config script full of all
sorts of stuff anyway. This is nothing by comparison.)

>   Ok, as long as there are those stupid installs to '/usr' on the native
> front, as long people must think how on earth the natively installed
> C libraries can be copied to the cross host.

Er, NFS? cp? tar? All of them work.

>  Linux is a good example
> about this stupidity in the very beginning. Instead of thinking how
> one could produce apps for Linux easily on ANY host, it was thought
> how one could produce apps for Linux ONLY on the Linux host and so
> trying to make cross-compiling to Linux as hard as possible.

It's not hard. Just lump everything in /lib into the same place as
everything in /usr/lib on the compilation host, and everything will
work fine.

>   Not using '--with-sysroot=' at all, but simply putting the '/lib'
> and '/usr' stuff below a '$sysroot' and then symlinking the
> '$sysroot/usr/include' and '$sysroot/usr/lib' to be seen as 'include'
> and 'lib' on the $gcc_tooldir, adding a couple more symlinks to the
> 'lib' and editing the absolute paths away from the 'libc.so', enables
> one to get a Linux-targeted GCC to work.

Indeed it does. (The libc.so absolute paths are... silly, but that's
not something you can blame on GCC. Best of luck convincing Ulrich
to change it.)

>  With 64-bit bi-arch targets
> one of course uses the default 'lib64' as the place here the
> $gcc_tooldir/lib' leads to... No need for '--with-sysroot=' with the
> 64-bit bi-arch targets either.

Yeah, but they're not really cross-compilers in that sense: they're

Re: 4.2 Project: "@file" support

[Russ Allbery]

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 wider scope than just gcc.

dig -t txt proxy-service.best.stanford.edu @leland-ns0

comes to mind.

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: 4.2 Project: "@file" support

[Mark Mitchell]

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:

functionname(&argc, &argv);

Let's name it something generic, and assume that *all* command line
fiddling will be done within that function, and that the application
never need worry about it - ever.


OK.


I suggest that DJGPP's implementation define the functionality (at
least, the parts that make sense to implmement globally), as we've had
over a decade of experience with it, and thus it's likely to cause the
least surprises:

http://www.delorie.com/bin/cvsweb.cgi/djgpp/src/libc/crt0/c1args.c?rev=1.10

(search for expand_response_files)


First, let me say that I don't feel strongly about anything after this 
point in this mail.  So, I can be pushed around pretty easily here; I'm 
more after some solution than any particular one.


I found the DJGPP code a little complicated, but I'm sure I can work it 
out.  I also did some additional experiments with MSVC and found some 
slightly odd behaviors, like double-quoting works, in general, but:


  "foo
  bar"

is actually two arguments.  I guess I'd argue that the behavior Windows 
people probably *most* expect is MSVC (rather than DJGPP), but that may 
not be true of GNU people in particular, who might be more likely to 
have used DJGPP.


However, I have a counter-proposal, which is that we use libiberty's 
existing buildargv.  That seems maximally consistent.  I didn't do that 
originally because I didn't know it was there, until very late in the 
game.  We would have to factor out the code so that we could avoid the 
buildargv behavior that creates a non-empty argv from an empty string, 
but other than that it seems like we could just leverage the quoting 
behavior that's already there.


Thanks,

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: 4.2 Project: "@file" support

[DJ Delorie]

> 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-delimited arguments.

3. Allow non-file "@string" left as-is (not fatal).

Uninitialized use warning message

[Kean Johnston]

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
`foo' to trigger the warning. What I would dearly love to see
is the warning message be a bit more informative, along the
lines of:

  foo.c:123: warning: `foo' might be used unitialized in this function
  foo.c:234: warning: possible use of unitialized `foo'
  foo.c:345: warning: possible use of unitialized `foo'

You get the idea. Does anyone else think this would be useful?
Do we even have sufficient data available to be able to produce
such warnings? I figured I'd ask first before diving into the code.

Kean

Re: Uninitialized use warning message

[Eyal Lebedinsky]

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 some code somewhere that used variable
> `foo' to trigger the warning. What I would dearly love to see
> is the warning message be a bit more informative, along the
> lines of:
> 
>   foo.c:123: warning: `foo' might be used unitialized in this function
>   foo.c:234: warning: possible use of unitialized `foo'
>   foo.c:345: warning: possible use of unitialized `foo'
> 
> You get the idea. Does anyone else think this would be useful?
> Do we even have sufficient data available to be able to produce
> such warnings? I figured I'd ask first before diving into the code.

Well, this is not this simple. It is usually easy for me to find where
it is used (possibly uninitialised). The harder part is finding the
control path that leads there without initialisation.

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 init 'msg', point [2] is where I
use it. I know that the program is safe, and if the flow analysis
can relate 'flag' and 'msg' then the warning would go away.

Which one would we want listed in the proposed new warning, 1 or 2?
Naturally, there can be multiple 1s and 2s for the same variable.

-- 
Eyal Lebedinsky ([EMAIL PROTECTED]) 
attach .zip as .dat

Re: 4.2 Project: "@file" support

[Mark Mitchell]

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 that.

(MSVC does not do this.  Presumably this explains the behavior under 3 
below.)



2. Support for "find -print0" which is more robust than
   whitespace-delimited arguments.


OK.


3. Allow non-file "@string" left as-is (not fatal).


OK.

(MSVC does not do this either.)

I'm not particularly concerned about differing from MSVC on these 
points; I'm just noting them for posterity.


--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: Uninitialized use warning message

[Kean Johnston]

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 init 'msg', point [2] is where I
use it. I know that the program is safe, and if the flow analysis
can relate 'flag' and 'msg' then the warning would go away.

Which one would we want listed in the proposed new warning, 1 or 2?

Definately 2. I wont say it is *impossible*, but I think
it is asking way too much of the compiler to warn about 1.
It implies a level of understanding of the flow of the
program that is completely unrealistic. However, warning at
2 should be trivial. Where this level of detail in the
warning is useful is if you have a particularly large function,
with the variables declared at the top (not at the top of, say,
and enclosing if() block). Its even worse when the code is
full of pre-processor conditionals. By telling me that 2
(or all instances of type 2), it saves me looking at *every*
usage of msg. It's just plain more useful, IMHO :)

Kean

Re: Cross Compiler Unix - Windows

[Daniel Jacobowitz]

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:58AM +0300, Kai Ruottu wrote:
>  The '--with-sysroot' tries to keep the 'proprietary' layouts even on
> the cross-hosts, where people could always use the "standard install
> layout for GCC", every GCC installed using just the same rules. So the
> situation where all crosscompilers use their own proprietary layouts
> has somehow been seen being better that trying to standardize the GCC
> installation layout.

No.  The point of --with-sysroot is so that you can build a native
compiler for some target, and a cross compiler to that same target, and
have them use the same layout.  The native layout is _not_ something
that we can change at this date, whatever you may like to think about
it.

>  Before trying to move the proprietary layouts into the peaceful?
> land of cross, it could have been better to ask the crosscompiler
> builders how they have solved these "copy the target headers and
> libs from the native system and put them to work with the cross-GCCs
> too" problems. Maybe then there had no reason for the '--with-sysroot'.
> Does it even work as one would expect it to work, solving those '/lib'
> and '/usr/lib' in the 'libc.so' script problems and so on?

Of course it does.  The absolute paths will be handled correctly by ld.

This was done to minimize the pain of building cross compilers to
"hosted" systems.  It seems to have worked, since everyone I've spoken
to who's used it finds it much more natural, and the process has less
undocumented voodoo than the --with-headers/--with-libs setup.

> better way to do just the same thing!" (Was the '--with-sysroot' made
> for people who are not as clever as we cross-GCC people who were
> considered being complete idiots? :-)

As one of the people who implemented this, I take offense at your
comments.  If you couldn't tell.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

memset() Optimization on x86-32 bit

[Kevin McBride]

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 supposed to reset the memory about to be freed.
Source code for the libteklti project is on SourceForge at:

http://cvs.sourceforge.net/viewcvs.py/libteklti/

Anyway, in gcc 4.0.1, I have noticed that the optimization for memset()
calls has a few extra instructions in the generated assembly that do not
need to be inserted.


If you look closely, you can see that %edi can be automatically loaded
directly without problems, and that (%eax) can be directly loaded into
(%esp).  Is this behavior intentional (for bugs I don't know about in
earlier processors) or could this optimization be fixed to use less 
instructions?



The following disassembly output is an example for the line:

0x08049172 : mov0x8(%ebp),%eax
0x08049175 : mov0x4(%eax),%edx
0x08049178 : mov0x8(%ebp),%eax
0x0804917b : mov(%eax),%ebx
0x0804917d : mov%ebx,%edi
0x0804917f : cld
0x08049180 : mov%edx,%ecx
0x08049182 : mov$0x0,%al
0x08049184 : repz stos %al,%es:(%edi)
0x08049186 : mov%ebx,%eax
0x08049188 : mov%eax,(%esp)
0x0804918b : call   0x8048c08 

associated C code:

#ifdef  TEKLTI_ENFORCE_PRIVACY
free(
memset(
uchrtofree->uchar_t_ascii,
'\0',
sizeof(char) * uchrtofree->uchar_t_asciilen
)
);
#else   /* not USE_386_ASM_ENFORCE_PRIVACY */



For reference:


Dump of assembler code for function ucharempty, for comparison:

From uchar.c:
0x0804913d : push   %ebp
0x0804913e : mov%esp,%ebp
0x08049140 : push   %edi
0x08049141 : push   %ebx
0x08049142 : sub$0x10,%esp
0x08049145 : cmpl   $0x0,0x8(%ebp)
0x08049149 : jne0x8049172 
0x0804914b : mov0x804c1cc,%eax
0x08049150 : mov%eax,0xc(%esp)
0x08049154 : movl   $0x35,0x8(%esp)
0x0804915c : movl   $0x1,0x4(%esp)
0x08049164 : movl   $0x804b120,(%esp)
0x0804916b : call   0x8048c58 
0x08049170 : jmp0x804919b 
0x08049172 : mov0x8(%ebp),%eax
0x08049175 : mov0x4(%eax),%edx
0x08049178 : mov0x8(%ebp),%eax
0x0804917b : mov(%eax),%ebx
0x0804917d : mov%ebx,%edi
0x0804917f : cld
0x08049180 <
ucharempty+67>: mov%edx,%ecx
0x08049182 : mov$0x0,%al
0x08049184 : repz stos %al,%es:(%edi)
0x08049186 : mov%ebx,%eax
0x08049188 : mov%eax,(%esp)
0x0804918b : call   0x8048c08 
0x08049190 : mov0x8(%ebp),%eax
0x08049193 : mov%eax,(%esp)
0x08049196 : call   0x8048c08 
0x0804919b : add$0x10,%esp
0x0804919e : pop%ebx
0x0804919f : pop%edi
0x080491a0 : pop%ebp
0x080491a1 : ret
End of assembler dump.


From uchar.386.c:

Dump of assembler code for function ucharempty:
0x08048fde : push   %ebp
0x08048fdf : mov%esp,%ebp
0x08048fe1 : mov0x8(%ebp),%ecx
0x08048fe4 : push   %edi
0x08048fe5 : mov(%ecx),%edi
0x08048fe7 : push   %edi
0x08048fe8 : mov0x4(%ecx),%ecx
0x08048feb : mov$0x0,%al
0x08048fed : repz stos %al,%es:(%edi)
0x08048fef : call   0x8048be0 
0x08048ff4 : pop%edi
0x08048ff5 : pop%edi
0x08048ff6 : mov%ebp,%esp
0x08048ff8 : pop%ebp
0x08048ff9 : jmp0x8048be0 
End of assembler dump.