Re: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

[Aaron W. LaFramboise]

Brian Dessent wrote:

Jesper de Jong wrote:


/home/jesper/gcc-4.1.2/configure --enable-threads=win32


Where do people keep getting this idea that Cygwin uses win32 threads? 
It doesn't, and you've most likely built a compiler that is subtly

broken in some way.  Cygwin uses pthreads, this should be


Jesper,

If you have the time and inclination, you might consider running the 
testsuite with --enable-threads and with --enable-threads=win32, and 
seeing if there's any difference, and report back here with the results.


I don't really see any compelling reason that win32 threads shouldn't 
work on Cygwin.  As far as I know, nothing about this choice is 
ultimately exposed to the user.  In fact, Win32 threads are quite likely 
to yield superior performance anywhere where it matters.


One place it might cause problems is if it enabled any of that mingwm or 
whatever stuff.

Re: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

[Aaron W. LaFramboise]

Brian Dessent wrote:

"Aaron W. LaFramboise" wrote:


I don't really see any compelling reason that win32 threads shouldn't
work on Cygwin.  As far as I know, nothing about this choice is
ultimately exposed to the user.  In fact, Win32 threads are quite likely
to yield superior performance anywhere where it matters.


There is a very compelling reason.  If you go creating threads behind
Cygwin's back by calling the Win32 API directly, you will quickly get
very wrong results as you try to use other features of Cygwin.  In order
to correctly emulate a posix API under Windows, Cygwin has to handle all
creation and deletion of resources, including threads, and the
corresponding bookkeeping to keep track of them.


The main thing --enable-threads controls is synchronization between 
threads, for example, when throwing exceptions.  In general, it does not 
control how threads are created, which has nothing to do with GCC.  (An 
exception is ObjC which needs to create a thread for a detach feature.)


Regardless, I'd be surprised if this was an issue, since the Cygwin DLL 
receives notification of every thread creation anyway, and can create 
any needed per-thread information at that time.  CreateThread() works 
just fine with Cygwin.  In fact, since Cygwin 1.3.13-1 (Oct 2002), 
Cygwin has even supported using these threads later pthreads calls.


However, I checked the source, and --enable-threads doesn't really work 
in this way anyway.  On *-*-cygwin, --enable-threads=win32 is equivalent 
to --disable-threads.  Similarly, on *-*-mingw32, 
--enable-threads==posix won't work.  Since most targets only allow a 
single thread type, and ignore all others, this option is sort of 
misleading, particularly as it doesn't tell you that your selection has 
been ignored, and has in fact had the opposite effect from what was 
intended.

Re: Inclusion in an official release of a new throw-like qualifier

[Aaron W. LaFramboise]

Jason Merrill wrote:

Sergio Giro wrote:

I perceived that many people think that the throw qualifiers, as
described by the standard, are not useful


Yes.  But that's not a reason to add a slightly different non-standard 
feature that would require people already using standard exception 
specifications to rewrite everything.  That's just a non-starter.


This is also the feature I'd like to see: a static checker for the 
existing throw specification feature.


I've been an advocate for eh specs, and I believe they are usable in 
their present form.  For reasons pointed out elsewhere, Java-esque 
static checking really isn't going to work for C++.  The only way that 
Java even gets away with it is why letting the vast majority of 
exceptions--those are derived from Error--slip through.  That is, Java 
throw(something) is equivalent to C++ throw(something, Error), where 
Java's Error is probably close to C++'s std::runtime_error. 
(Unfortunately std::bad_alloc and similar don't derive from 
std::runtime_error or share a common parent.)


The main problem with eh specs in their present form, besides poor 
support on some non-GCC compilers, is the lack of tools available to 
audit the specs.  This is a challenge to implement, as it needs to use 
non-intrusive decorators and heuristics to allow the user to indicate 
cases where exceptions logically won't propagate, even though they 
'theoretically could.'  Complete static checking would end up being the 
equivalent of -Weffc++: completely useless.


But I do think the compiler is the right place to do this sort of 
checking, as it needs to have available to it all of the same sorts of 
analysis as a compiler.  Good luck, Sergio, if you want to work on this.

Backport fix for spurious anonymous ns warnings PR29365 to 4.2?

[Aaron W. LaFramboise]

I discovered PR29365 today while testing 4.2.0 RC2 on a client's 
codebase.  This causes some of my code, based on the popular pimpl 
idiom, to generate warnings, even with no warning flags specified.  If 
there's a way to turn it off without patching the source, I can't find it.


Given the pervasiveness of the pimpl idiom in C++, and the increasing 
use of anonymous namespaces in modern code, it is possible that this 
will be a serious problem for some C++ developers, that may hinder the 
adoption of 4.2.  It's not hard to imagine that this could come up in a 
lot of other weird places that uses anonymous namespaces, too.


Does this qualify as a regression?  Does anyone else think this is a 
serious problem?

Re: request for timings - makedepend

[Aaron W. LaFramboise]

real0m18.740s
user0m0.010s
sys 0m0.020s

i686-pc-mingw32
Windows XP Professional Ver 5.1 Build 2600 Service Pack 2
1.4GHz Pentium 4 768MB RAM

I have no preference regarding makedepend.


Aaron W. LaFramboise

Non-bootstrap build status reports

[Aaron W. LaFramboise]

Is there a reason why non-bootstrap build status reports are not
archived?  For example, for the many targets that are only used in cross
configurations, it would be nice to see if they are working.

Also, it might be nice to have a record of negative build reports.  For
instance, the build status page might have section for negative builds
listing reports of failed builds that might serve as a quick means to
determine the health of a broken port.


Aaron W. LaFramboise

getopt.h getopt() decl broken for many targets

[Aaron W. LaFramboise]

Targets, such as Windows, that don't have getopt() will probably have
get the following error when compiling binutils.

gcc -DHAVE_CONFIG_H -I.
-I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I. -D_GNU_SOURCE
-I. -I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I../bfd
-I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils/../bfd
-I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils/../include
-D__USE_MINGW_FSEEK
-I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils/../intl -I../intl
-DLOCALEDIR="\"/aaronwl/cs/env/mingw-head/20040323/share/locale\""
-Dbin_dummy_emulation=bin_vanilla_emulation   -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Werror -g -O2 -c
/aaronwl/cs/compilers/binutils/src/cvs/src/binutils/strings.c
In file included from
/aaronwl/cs/compilers/binutils/src/cvs/src/binutils/strings.c:65:
/aaronwl/cs/compilers/binutils/src/cvs/src/binutils/../include/getopt.h:116:
warning: function declaration isn't a prototype
make[4]: *** [strings.o] Error 1

This is due to this code:

#if !HAVE_DECL_GETOPT
#if defined (__GNU_LIBRARY__) || defined (HAVE_DECL_GETOPT)
/* Many other libraries have conflicting prototypes for getopt, with
   differences in the consts, in unistd.h.  To avoid compilation
   errors, only prototype getopt for the GNU C library.  */
extern int getopt (int argc, char *const *argv, const char *shortopts);
#else
#ifndef __cplusplus
extern int getopt ();
#endif /* __cplusplus */
#endif
#endif /* !HAVE_DECL_GETOPT */

Is the situation described in this comment still true?  Would it be
possible to turn this whitelist into a blacklist?

Re: Fixing Bugs (Was: A Suggestion for Release Testing)

[Aaron W. LaFramboise]

chris jefferson wrote:

> Working code is also of course by far the most convincing argument 
> :).

Boosters, FreeBSD hackers, and I'm sure tons of others are calling this
the "Bicycle shed effect."

<http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING>

I agree.  Preliminary discussion is hugely more vulnerable to bicycle
shed color disagreements, where participants may feel that all of the
colors have not been completely examined, compared to tested working
code, where others will have more confidence that due diligence has been
applied.

In all of the open source world I have seen, posting code is always better.


Aaron W. LaFramboise

Re: RFC: weakref GCC attribute and .weakref assembly directive

[Aaron W. LaFramboise]

Hello,

Alexandre Oliva wrote:


What we need, in contrast, is some means to define an alias that
doesn't, by itself, cause an external definition of the symbol to be
brought in.  If the symbol is referenced directly elsewhere, however,
then it must be defined.  This is similar to the notion of weak
references in garbage collection literature, in which a strong
reference stops an object from being garbage-collected, but a weak
reference does not.  I've decided to name this kind of alias a
weakref.


Could you compare your novel weak references to PECOFF's notion of "weak 
externals"?


.weak sym1 = sym2  # Analogous to: .weakref sym1, sym2

"If a definition of sym1 is linked, then an external reference to the 
symbol is resolved normally.


If a definition of sym1 is not linked, then all references to the weak 
external for sym1 refer to sym2 instead.


The external symbol, sym2, must always be linked; typically it is 
defined in the module containing the weak reference to sym1" (PECOFF 6.0 
5.5.3).


Note that PECOFF weak external symbols have external linkage, but they 
will never be used to resolve an undefined reference in another object 
at link-time.



I am thinking that the difference is that PECOFF weak externals can be 
resolved by definitions anywhere in the final link, while your new weak 
references can only be overriden by definitions within the same 
translation unit.  Does this seem correct?



Thanks,

Aaron W. LaFramboise

Re: RFC: weakref GCC attribute and .weakref assembly directive

[Aaron W. LaFramboise]

Alexandre Oliva wrote:

On Oct 13, 2005, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

>

The difference is that ".weak sym1 = sym2" resolves to sym1 (if
available) else sym2; but ".weakref sym1, sym2" resolves to sym2 (if
available) else zero.  Also sym1 does not become an external, only a
local alias, IIRC.


Yep.  In `.weak sym1 = sym2', sym1 is a weak alias, which I actually
contrast with a weakref in the spec text I posted.


Well, that syntax is specific to the PE port as far as I know, and the 
semantics don't quite match weak aliases, which I understand to be the 
equivilent of:


.setsym1, sym2
.weak   sym1

For instance, in PECOFF 'weak externals' (probably a rather misleading 
name),


> A weak alias cannot reference an undefined symbol, weak or strong.

this statement is not true.  This is because PECOFF's 'weak externals' 
are actually a unique storage class, and so it can do special stuff.


But thank you guys for your help; it answers my question.


Aaron W. LaFramboise

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Aaron W. LaFramboise]

I have also recently become interested in a GCC port for the 18F.

Can someone summarize who--if anyone--is working on this, how much 
progress he has made so far (Is his work based on mainline?), and any 
expected future milestones?


(And who are all of the people in the CC list?  Is there some other list 
discussing this?)


I think that the major work that will need to be done for this port is 
figuring out how to get segmentation to work.  Some other potential 
ports need this too, so if there's any way to do this in a way that all 
ports can benefit, that would be great.  I think this is definitely 
possible, but it seems like it may take some effort--particularly to get 
the changes into a form acceptable for inclusion into FSF GCC.


The way I would do this (and will, perhaps, if noone else intends to 
work on this any time soon) is to consider the access bank (low 128 GPRs 
and some of the high 128 SPRs) as the GCC registers.  (I am not sure if 
~140 registers is too many for GCC to handle effectively; Are there 
ports that use this many?)  This will yield a port that can deal with at 
least 512 bytes of memory, I think.  Implementing segmentation will give 
it access to the rest of the banks.

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Aaron W. LaFramboise]

Colm O' Flaherty wrote:

Have you checked out SDCC?  This may support the specific devices you're 
interested in.  For my part, I'm more interested in a GCC port than SDCC 
though, as I feel there is an awful lot more to be gained from a gcc 
port in the longer term.


As near as I can tell, the support in SDCC for the 18F is pretty weak. 
I haven't actually tried it, but comments from the main person working 
on 18F support in SDCC lead me to beleive it has a way to go yet.


But really, I don't understand why SDCC needs to exist.  GCC provides 
95% of any ordinary C compiler port.  It has better support for the C 
language (and other languages) than something like SDCC will likely ever 
have; it also has a superior optimizer, even if this optimizer is not 
presently tuned for small devices.


In any case, I'm mostly interested in C++.

I will probably start working on a 18F back-end if no definite plans for 
implementing a complete port materialize 'soon.' (that is, if no-one 
else seems likely to produce anything within the next few months)

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Aaron W. LaFramboise]

François Poulain wrote:


I think so. Microchip have done a modified version of GCC-3.3 with
DSPICs support, so we have got a heavy good base to work on the
instruction set, wich is similar for PIC18. DSPIC is a 16 bit CPU, so is
memory isn't segmented.


Just as a reminder, even though the Microchip code is covered by the 
GPL, code based on it won't be acceptable for inclusion into FSF GCC 
unless you can get Microchip to sign a copyright assignment, which seems 
unlikely.  Any code in FSF GCC needs to be written by someone with a 
copyright assignment to FSF, or at least a public domain release.  (I'm 
not sure on the exact rules here.  Someone at the FSF would know exactly.)

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Aaron W. LaFramboise]

François Poulain wrote:


If I'm right, here are copyright assignments to FSF for the Microchip's
contributions for GCC.


Unfortunately, this is not good enough.  A copyright assignment is a 
formal contract that must be physically signed and sent to the FSF.  See 
 for details.


Since as far as I can tell John Elliot has not attempted to include his 
changes in the official FSF GCC, it is very that he has a copyright 
assignment.  Any work based on work by him would require an assignment 
from him also--and most likely his employer, Microchip.


There is an official list somewhere of who has copyright assignments on 
file.  Alternately, whatever work he has done were thought to be 
valuable, someone could just email him and ask. :)

Re: GCC Port (gcc backend) for Microchip PICMicro microcontroller

[Aaron W. LaFramboise]

I send a message to John Elliott's listed address yesterday, and I have 
not yet received an immediate response.  I will post to this list if I 
receive anything from him.


So, I'd caution anyone away from basing any work on the dsPIC port until 
some specific understanding is established with Microchip--if you want 
it to be included in FSF GCC.

Re: How does g++ implement error handling?

[Aaron W. LaFramboise]

Jonathan Wakely wrote:

> On Mon, Feb 21, 2005 at 12:32:52PM +0800, Euler Herbert wrote:

>>be somewhere, but I did no find it. Could somebody tell me the 
>>outline of the unwinding process? 

> I think this behaviour is defined by this spec:
> http://www.codesourcery.com/cxx-abi/abi-eh.html

What's awful about this is that the interesting portion, "Level III"
<http://www.codesourcery.com/cxx-abi/abi-eh.html#imp-intro>, is
basically empty.

I'm also interested in any overview-level information about the Dwarf2
unwinding mechanism.


Aaron W. LaFramboise

[Windows] Fixing fprintf errors breaking bootstrap?

[Aaron W. LaFramboise]

I am still seeing errors such as this bootstrapping trunk with -Werror. 
 I thought all of this was supposed to be resolved?


../../svn/gcc/bt-load.c: In function 'migrate_btr_defs':
../../svn/gcc/bt-load.c:1415: error: ISO C does not support the 'I64' 
ms_printf length modifier


What needs to be fixed here?  Does HOST_WIDEST_INT_PRINT_DEC need to 
change, or something else?

Re: [Windows] Fixing fprintf errors breaking bootstrap?

[Aaron W. LaFramboise]

Aaron W. LaFramboise wrote:
I am still seeing errors such as this bootstrapping trunk with -Werror. 
 I thought all of this was supposed to be resolved?


OK, this is http://gcc.gnu.org/PR25502

Sorry for the noise.

Apparently the reason this has gone on so long is that most people are 
crossbuilding mingw32 or using --disable-werror.

Pedantic error on address-of main breaks libjava bootstrap

[Aaron W. LaFramboise]

When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails with:


./sysdep/backtrace.h: In function '_Unwind_Reason_Code 
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*), 
_Jv_UnwindState*)':
./sysdep/backtrace.h:107: error: ISO C++ forbids taking address of function 
'::main'


On mingw32, backtrace.h is a symlink or copy to i386/backtrace.h, which 
is what has this problem:



  if (ctx.meth_addr == (_Jv_uintptr_t)jv_runmain
  || ctx.meth_addr == (_Jv_uintptr_t)_Jv_ThreadStart
  || (ctx.meth_addr - (_Jv_uintptr_t)main) < 16)
break;


The code needs the address of main to stop the unwind.  What is the 
proper way to suppress this warning?  __extension__ doesn't seem to help.


(I'm actually not sure what has changed to cause this warning to start 
happening now.)

Re: Pedantic error on address-of main breaks libjava bootstrap

[Aaron W. LaFramboise]

Andrew Haley wrote:

Aaron W. LaFramboise wrote:

When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
with:


./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
_Jv_UnwindState*)':
./sysdep/backtrace.h:107: error: ISO C++ forbids taking address of
function '::main'

On mingw32, backtrace.h is a symlink or copy to i386/backtrace.h, which
is what has this problem:


  if (ctx.meth_addr == (_Jv_uintptr_t)jv_runmain
  || ctx.meth_addr == (_Jv_uintptr_t)_Jv_ThreadStart
  || (ctx.meth_addr - (_Jv_uintptr_t)main) < 16)
break;

The code needs the address of main to stop the unwind.  What is the
proper way to suppress this warning?  __extension__ doesn't seem to help.

(I'm actually not sure what has changed to cause this warning to start
happening now.)


Please send the command line that led to this.


Here's the complete command line.

/mingw/src/gccf/./gcc/xgcc -shared-libgcc -B/mingw/src/gccf/./gcc 
-nostdinc++ -L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src 
-L/mingw/src/gccf/i386-pc-mingw32/libstdc++-v3/src/.libs 
-L/mingw/src/gccf/i386-pc-mingw32/winsup/mingw 
-L/mingw/src/gccf/i386-pc-mingw32/winsup/w32api/lib -isystem 
/mingw/src/svn/winsup/mingw/include -isystem 
/mingw/src/svn/winsup/w32api/include -B/mingw/i386-pc-mingw32/bin/ 
-B/mingw/i386-pc-mingw32/lib/ -isystem /mingw/i386-pc-mingw32/include 
-isystem /mingw/i386-pc-mingw32/sys-include -DHAVE_CONFIG_H -I. 
-I../../../svn/libjava -I./include -I./gcj -I../../../svn/libjava 
-Iinclude -I../../../svn/libjava/include 
-I../../../svn/libjava/classpath/include -Iclasspath/include 
-I../../../svn/libjava/classpath/native/fdlibm 
-I../../../svn/libjava/../boehm-gc/include -I../boehm-gc/include 
-I../../../svn/libjava/libltdl -I../../../svn/libjava/libltdl 
-I../../../svn/libjava/.././libjava/../gcc 
-I../../../svn/libjava/../zlib -I../../../svn/libjava/../libffi/include 
-I../libffi/include -fno-rtti -fnon-call-exceptions -mthreads 
-fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 
-ffloat-store -fomit-frame-pointer -Usun -fno-omit-frame-pointer -Wextra 
-Wall -D_GNU_SOURCE -DPREFIX=\"/mingw\" 
-DTOOLEXECLIBDIR=\"/mingw/lib/gcc/i386-pc-mingw32/4.4.0\" 
-DJAVA_HOME=\"/mingw\" 
-DBOOT_CLASS_PATH=\"/mingw/share/java/libgcj-4.4.0.jar\" 
-DJAVA_EXT_DIRS=\"/mingw/share/java/ext\" 
-DGCJ_ENDORSED_DIRS=\"/mingw/share/java/gcj-endorsed\" 
-DGCJ_VERSIONED_LIBDIR=\"/mingw/lib/gcj-4.4.0-10\" 
"-DPATH_SEPARATOR=\";\"" -DECJ_JAR_FILE=\"\" 
-DLIBGCJ_DEFAULT_DATABASE=\"/mingw/lib/gcj-4.4.0-10/classmap.db\" 
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.4.0-10/classmap.db\" -g -O2 
-MT stacktrace.lo -MD -MP -MF .deps/stacktrace.Tpo -c 
../../../svn/libjava/stacktrace.cc  -DDLL_EXPORT -DPIC -o .libs/stacktrace.o


Sorry, I noticed now that there isn't actually a -pedantic anywhere in 
there.  Removing -Wextra and -Wall have no effect, so this is obviously 
a default error.  Adding -fpermissive turns the error into a warning.


What do you think?

Inconsistent use of allocator wrapper macros in libiberty

[Aaron W. LaFramboise]

Quite a few files in libiberty use XNEWVEC as a replacement for 
malloc(), but the they are being paired with plain free(); XDELVEC is 
not being used.


Is there some reason for the inconsistency, such as some transitional 
issue, or should this be fixed?

GRAPHITE Prerequisites Documentation, System Issues

[Aaron W. LaFramboise]

I'm happy to see that GRAPHITE it is in trunk now!

I don't see any documentation of prerequisites in install.texi yet; 
perhaps we should add this so users can figure out what they need to do 
to get this framework to work.


In fact, 'grep -i graphite gcc/doc/*' doesn't match anything, so I guess 
documentation is still in progress?


Also, are there any system-specific issues that need to be worked on (eg 
on Windows), or should GRAPHITE and its support libraries pretty much 
work on all host platforms?

Re: old but current libiberty/strsignal vs. cygwin

[Aaron W. LaFramboise]

Hi Jay,

Thanks for bringing this up.  I mainly work on the native-ish Windows 
targets (MinGW), so I'm not really a Cygwin guy, but see below.


Jay wrote:


 I'm still testing this but it does seem to be two smoking guns.
 The first one shot a blank but I doubt I'll find a third. :)

...
> Can someone vet and apply these changes? Thanks.

If you figure out a definitive fix, please submit it to gcc-patches@ in 
the proper format.  See  for the 
instructions on specifically how to submit a patch.


You will need to update your patch to SVN trunk or a recent 4.4 
snapshot, since that is what it would be applied to.



 Nobody builds gcc + cygwin in an integrated tree?
 I wish I could integrate more into The One Tree.
 I so dislike everything being separate..


Probably not, especially because relatively few people are doing their 
own Cygwin builds at all.



Similarly, this is kind of yucky but I guess ok:

...

Or declare them __declspec(dllimport) on Cygwin (or whatever is the gcc equiv).


I think libiberty it should do this conditional on Cygwin.  If that 
seems to fix it, you should submit a patch.  The ideal is to avoid using 
auto-import entirely if possible.

Re: Problems building Windows hosted mips-elf toolchain using Linux as build machine

[Aaron W. LaFramboise]

Hi Øyvind,

Øyvind Harboe wrote:

I'm trying to build a mips-elf toolchain hosted on Windows using
Linux as the build machine but I'm running into the following error:



mips-elf-gcc -nostdinc -isystem /tmp/gccbuild/build/gcc/./gcc/include
-B/tmp/gccbuild/build/gcc/mips-elf/newlib/ -isystem
/tmp/gccbuild/build/gcc/mips-elf/newlib/targ-include -isystem
/tmp/gccbuild/src/gcc/newlib/libc/include
-B/tmp/gccbuild/build/gcc/mips-elf/libgloss/mips
-L/tmp/gccbuild/build/gcc/mips-elf/libgloss/libnosys
-L/tmp/gccbuild/src/gcc/libgloss/mips -O2 -g -g -O2 -msoft-float -O2
-O2 -g -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -G 0 -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc  -I. -I. -I../../.././gcc
-I/tmp/gccbuild/src/gcc/libgcc -I/tmp/gccbuild/src/gcc/libgcc/.
-I/tmp/gccbuild/src/gcc/libgcc/../gcc
-I/tmp/gccbuild/src/gcc/libgcc/../include  -DHAVE_CC_TLS -o
_fixunssfsi.o -MT _fixunssfsi.o -MD -MP -MF _fixunssfsi.dep
-DL_fixunssfsi -c /tmp/gccbuild/src/gcc/libgcc/../gcc/libgcc2.c  \
-DLIBGCC2_UNITS_PER_WORD=4
In file included from /tmp/gccbuild/src/gcc/libgcc/../gcc/libgcc2.c:1697:
/tmp/gccbuild/src/gcc/newlib/libc/include/limits.h:130:26: error: no
include path in which to search for limits.h


What sort of thing is at this location in limits.h?  Unless someone 
knows something more about this, you will need to track down this 
specific failure.


Run re-run this specific command that is failing with -v to get more 
useful information about the search path.


GCC is supposed to provide a MIPS-target limits.h, and apparently thats 
not working out for some reason.



- trying to build a GCC toolchain under Windows seems like a complete
non-starter


It is fairly straightforward on Cygwin actually, and should work about 
as easily as the Linux build.  It will be substantially slower, however.


For a non-Cygwin native Windows (MinGW) build, see
.

I have no idea if that would solve your problem though. :)

By the way, this sort of question is best for [EMAIL PROTECTED], 
where people know more about these sorts of relatively common build 
problems.  gcc@ is for discussion of developing GCC specifically.

Re: [Cygwin] some random build breaks

[Aaron W. LaFramboise]

Jay wrote:


Creating library file: ./shlib/libgcc_s.a.tmp
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: warning: ca
nnot find entry symbol [EMAIL PROTECTED]; defaulting to 10001000
_absvsi2_s.o: In function `__absvsi2':
/src/gccsvn/libgcc/../gcc/libgcc2.c:237: undefined reference to `_abort'

...

collect2: ld returned 1 exit status
make[1]: *** [libgcc_s.dll] Error 1


Can you please try the attached patch to see if it fixes things, and let 
me know the result?  Thanks in advance.




java/net/natVMInetAddress.cc:42: error: declaration of C function 'int gethostna
me(char*, int)' conflicts with
/src/gcc/newlib/libc/include/sys/unistd.h:227: error: previous declaration 'int
gethostname(char*, size_t)' here

...

Probably the right fix here is some configury to look for the declaration of 
gethostname
and if it is found, be sure to #include where it is found, and not declare it 
one's self?


Yes.  This is a problem with libjava's autoconfigury. 
HAVE_GETHOSTNAME_DECL should be defined, but for some reason isn't.  If 
you examine the configury files in libjava/ such as config.log, 
configure, and configure.ac, you probably will find some clues regarding 
whats happening here.


2008-09-14  Aaron W. LaFramboise  <[EMAIL PROTECTED]>

* config/i386/t-cygming (SHLIB_C): Remove.
* config/i386/t-cygwin (SHLIB_C): Add all system libraries.

Index: gcc/config/i386/t-cygming
===
--- gcc/config/i386/t-cygming   (revision 140362)
+++ gcc/config/i386/t-cygming   (working copy)
@@ -54,7 +54,6 @@ SHLIB_MAP = @shlib_map_file@
 SHLIB_OBJS = @shlib_objs@
 SHLIB_DIR = @multilib_dir@/shlib
 SHLIB_SLIBDIR_QUAL = @shlib_slibdir_qual@
-SHLIB_LC = -luser32 -lkernel32 -ladvapi32 -lshell32
 
 SHLIB_LINK = $(LN_S) $(SHLIB_MAP) $(SHLIB_MAP).def && \
if [ ! -d $(SHLIB_DIR) ]; then \
Index: gcc/config/i386/t-cygwin
===
--- gcc/config/i386/t-cygwin(revision 140362)
+++ gcc/config/i386/t-cygwin(working copy)
@@ -15,4 +15,4 @@ cygwin2.o: $(srcdir)/config/i386/cygwin2
$(srcdir)/config/i386/cygwin2.c
 
 # Cygwin-specific parts of LIB_SPEC
-SHLIB_LC += -lcygwin
+SHLIB_LC = -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron W. LaFramboise]

Aaron Gray wrote:

One issue that might affect many some is that COM doesn't work. 
 has a patch that 
is pending review I guess, but probably won't go into 4.2.



Does this effect XPCOM meaning Mozilla and friends will not compile ?


It is triggered anywhere multiple inheritance is combined with stdcall. 
 Since I believe XPCOM uses stdcall on Windows (but "cdecl" on other 
targets), I believe the answer here is 'Yes, Mozilla will not compile.'


I think it's likely that mingw.org will include this fix in their own 
releases of 4.2, which is probably a bad thing, as it makes the need to 
get this fix into official GCC sources seem less urgent.  A lot of GCC 
patches for Windows-related issues tend to stall for a long time in this 
state; I'm not really sure why.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Aaron W. LaFramboise]

michael.a wrote:


So in closing, I'm interested in any ideas / advice, but compromising the
existing codebase is completely out of the question. You have my
appreciation in advance naturally...


I suspect the proper solution here is something from www.boost.org.  You 
didn't say exactly what you needed, but if its anything related to a 
common programming pattern, Boost has probably already implemented it in 
a portable or standard manner.  See 
.


In particular, see Boost optional, and aligned_storage in Boost typetraits.

Other people have already pointed it out, but I'll say it again: 
language extensions are almost always the wrong solution for these sorts 
of problems.

Re: Bug in gcc: assignment to non-lvalue

[Aaron W. LaFramboise]

Michiel de Bondt wrote:

Using strings to show my point was not a good idea. You can add a field 
"int number" to the struct and perform similar operations (with = 
instead of strcpy).


But even with strings, gcc should give an error like: "strcpy(const 
char*, const char*) does not exists". In case of a "typedef char 
string100[100]", gcc behaves correctly by ringing alarm bells. So it 
seems to be the . operator that behaves incorrectly.


You should distill a minimum and complete testcase that uses = to 
demonstrate the bug.  The example you gave does not assign to an r-value 
at all, as near as I can tell.  As Andrew points out, the array 
reference will decay to a pointer, which is passed to strcpy.  You may 
want to confirm on comp.lang.c++ or with another C++ compiler that the 
code is, in fact, invalid.


Thanks for looking into this. :)

Re: missing optimization - don't compute return value not used?

[Aaron W. LaFramboise]

Richard Li wrote:


Right, page 211 of the C++ standard (2003) explains when copy-ctor and
dtor are allowed to be optimized away. But the two circumstances are
both like this:
A is constructed; A is copy-constructed to B; A is destructed
Here A is a temporary object in some sense, and the standard allows
for directly constructing B.
However, Neal expected the compiler to optimize "A is constructed; A
is destructed" away. I find nowhere in the standard that allows this.


I think it would fall under the "as-if" rule.  The special rules you 
mention are only necessary if it causes a behavior change.


I think the biggest problem here is that GCC will not elide calls to the 
allocator.  This is a subject of some controversy--even though its 
probably difficult to do such optimization anyway.  It's not quite clear 
that such optimization is legal under the as-if rule.


For example, the code you have written will throw std::bad_alloc if your 
system is out of memory.  The code that you would like it to be 
optimized to would not do that, which is a behavior change.


This has been discussed a few times before.  See, for example, this 
thread .


So, you should probably never count on an optimizer removing calls to 
anything that touches memory management.  What's usually done, as 
Richard Li points out, is to write your code in such a way that such 
optimization is not necessary.