> This patch is an improved version over the one proposed in
Please avoid cross-posting. This should go on [EMAIL PROTECTED] only.
--
Eric Botcazou
On Jul 10, 2006, at 6:20 PM, Mike Stump wrote:
The next problem after that one is that:
ext/pb_ds/detail/binary_heap_/binary_heap_.hpp:235: internal
compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instru
> > Anyone have a fix, workaround, or other suggestion?
>
> Yes don't use --with-dwarf2 :).
Only a short term workaround... ;)
> This is PR 26504:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
Comment #8 there seems on-the-mark, so the PR 26015 fix has
two half-confirmations now:
> Also
On Monday 10 July 2006 22:42, [EMAIL PROTECTED] wrote:
> > Snapshot gcc-4.2-20060708 is now available on
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060708/
>
> something is brkoen here ...
> [~/gcc]
>
> >../gcc-src/gcc-4.2-20060708/gcc/configure
>
ups, should of course have been
../gcc-src/gc
Gosh, so close...
I found that the below patch gets me one step closer to it building.
I'm sure it is wrong... but it should be enough of a hint for the
right person to know how to fix it.
Doing diffs in libstdc++-v3:
--- libstdc++-v3/include/ext/codecvt_specializations.h.~1~
2005-1
Andreas Jaeger wrote:
# Fix for argument ‘clean_text_p’ might be clobbered by ‘longjmp’ or ‘vfork’
unprotoize.o-warn = -Wno-error
This is OK.
PR 21161 and PR 24239 are different instances of the same problem, so we
don't need another bug report for this. The previously mentioned PR
21059 is
This patch is an improved version over the one proposed in
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00098.html
It doesn't introduce any features. The main difference is the removal
of TREE_CONSTANT_OVERFLOW check from real_isinteger function,
following the new policy about not handling overflo
> I am trying to make a configure change in the libstdc++-v3 directory but
> when I run aclocal (even on an unmodified libstdc++-v3 directory from
> the top-of-tree), I get an error message. Does anyone else see this?
The current fashion for regenerating the config/make bits is to just run:
aut
> My rule of thumb: Check the options in automake's generated
> Makefile.in.
>
> You probably need a -I path.
>
> --
> Daniel Jacobowitz
> CodeSourcery
Ah, I see "ACLOCAL_AMFLAGS = -I . -I .. -I ../config", if I add those
-I options to my aclocal call I get no errors or warnings when running
On Mon, Jul 10, 2006 at 03:14:36PM -0700, Steve Ellcey wrote:
>
> I am trying to make a configure change in the libstdc++-v3 directory but
> when I run aclocal (even on an unmodified libstdc++-v3 directory from
> the top-of-tree), I get an error message. Does anyone else see this?
My rule of thu
I am trying to make a configure change in the libstdc++-v3 directory but
when I run aclocal (even on an unmodified libstdc++-v3 directory from
the top-of-tree), I get an error message. Does anyone else see this?
[hpsje] $ aclocal
aclocal:configure.ac:85: warning: macro `AM_PROG_LIBTOOL' not foun
On Jul 11, 2006, at 4:49 AM, David Brownell wrote:
Hi,
Anyone have a fix, workaround, or other suggestion?
Yes don't use --with-dwarf2 :).
This is PR 26504:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26504
Also someone should try the patch in PR 26015:
http://gcc.gnu.org/bugzilla/show_bug
David Brownell wrote:
/home/tux/avr/gcc/obj-avr/./gcc/xgcc -B/home/tux/avr/gcc/obj-avr/./gcc/
-B/usr/local/avr/avr/bin/ -B/usr/local/avr/avr/lib/ -isystem
/usr/local/avr/avr/include -isystem /usr/local/avr/avr/sys-include -O2 -O2 -g
-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Ws
On Jul 10, 2006, at 1:24 PM, Laurynas Biveinis wrote:
Do such changes require ChangeLog entries?
For my own beyond trivial fixes that I catch quickly (say, less than
24 hours), normally I just fix them with a `fix typo' type svn log
entry. When in doubt, or if you're fixing someone else's
> Snapshot gcc-4.2-20060708 is now available on
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060708/
something is brkoen here ...
[~/gcc]
>../gcc-src/gcc-4.2-20060708/gcc/configure
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system
On Mon, Jul 10, 2006 at 01:34:12PM -0700, Steve Kargl wrote:
> It's my understanding that every change requires a ChangeLog
> entry. There is now no consistent record of the difference
> between 115310 and 115311 without actually looking at "svn log
> fixincludes/Makefile.in".
>
> Perhaps, a quic
On Mon, Jul 10, 2006 at 11:24:55PM +0300, Laurynas Biveinis wrote:
> >You forgot a ChangeLog entry for
> >
> >
> >r115313 | lauras | 2006-07-10 12:44:48 -0700 (Mon, 10 Jul 2006) | 2 lines
> >
> >Fix spaces to tabs in the last c
You forgot a ChangeLog entry for
r115313 | lauras | 2006-07-10 12:44:48 -0700 (Mon, 10 Jul 2006) | 2 lines
Fix spaces to tabs in the last commit.
I'm not sure. I think that my ChangeLog entry by my previous commit
(the br
This patch broke building GCC because Makefile indention was done with
spaces instead of a TAB.
Obvious fix commited, r115313. That will teach me how to think "oh
well that's a tiny patch I sent a month ago, I'll just copy it from
the mail archives instead of locating it on my disk".
Sorry.
--
On Jul 9, 2006, at 10:52 PM, Vladimir 'Yu' Stepanov wrote:
I would like to offer one expansion for C/C++.
Did you just reinvent downcasting in C++? If so, C++ already has
that feature!? As for C, C, I'd claim C already has that feature[1],
you merely have to put in a #define into your lib
Hi,
I was building a AVR cross compiler from current GCC trunk, and got an error.
Build system was Ubuntu 6.06 on an Athlon, using the latest from CVS binutils
but otherwise configured exactly as shown in
http://www.nongnu.org/avr-libc/user-manual/install_tools.html
The assertion failure that
Will fix right now.
2006/7/10, Jan-Benedict Glaw <[EMAIL PROTECTED]>:
On Mon, 2006-07-10 17:58:19 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: lauras
> Date: Mon Jul 10 17:58:18 2006
> New Revision: 115310
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115310
> Log:
>
On Mon, 2006-07-10 17:58:19 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: lauras
> Date: Mon Jul 10 17:58:18 2006
> New Revision: 115310
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115310
> Log:
> fixincludes:
> 2006-07-10 Laurynas Biveinis <[EMAIL PROTECTED]>
>
>
On Jul 10, 2006, at 6:57 AM, jacob navia wrote:
What is the procedure for registering the frame info?
If you don't get an answer, you may have to debug it. Just follow
what something like eh6.C from the C++ testsuite does, and what it
calls, when, and with what data, then mirror the eh6.C
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> writes:
> Current syntax C/C++:
>
> load_ptr = typeof(load_ptr)(((char *)init_ptr) - \
>offsetof(typeof(init_ptr), field);
>
> The offered syntax:
>
> &load_ptr->field = init_ptr;
Interesting idea, but C/C++ programmers expect th
On Fri, Jul 07, 2006 at 10:56:08PM -0400, Robert Dewar wrote:
> That's not true, thread local storage can be done simply by mapping
> hardware on some machines, where you swap maps on a context switch.
Not with the semantics we have for __thread, which asserts
that its address is valid in all thre
In http://gcc.gnu.org/ml/gcc/2006-07/msg00156.html, your wrote:
A paper at this year's GCC Summit talked about this:
http://www.gccsummit.org/2006/view_abstract.php?content_key=18
You might like to follow up with Edmar (the author of the paper).
But that was about optimizing the trees for an
Hi
I have now everything in place for dynamically register the
debug frame information that my JIT (Just in time compiler)
generates.
I generate a CIE (Common information block), followed by
a series of FDE (Frame Description Entries) describing
each stack frame. The binary code is the same as g
A paper at this year's GCC Summit talked about this:
http://www.gccsummit.org/2006/view_abstract.php?content_key=18
You might like to follow up with Edmar (the author of the paper).
Cheers, Ben
Hi,
while dealing with autogenerated code I found that GCC often outputs compare
trees instead of branch tables for switch statements. I found that GCC uses the
density of case labels within their spanned range as the key criterion. If the
density of labels is smaller than 10% (33% for size op
30 matches
Mail list logo
