RTL alias analysis
Hi everybody, Im interested whether there is gcc support (at the RTL level) after unrolling which allows to disambiguate memory accesses present in RTL constructs (specially among memory accesses generated due to unrolling) for machines that do not support indexed addressing modes. I am aware of an article by Sanjiv Gupta and Naveen Sharma on alias analysis at the RTL level, which was published in the GCC 2003 summit. Are there any further gcc developments of this work or is there a patch concerning this work? thanks in advance, Alex Turjan No Cost - Get a month of Blockbuster Total Access now. Sweet deal for Yahoo! users and friends. http://tc.deals.yahoo.com/tc/blockbuster/text1.com
Re: GSOC Student application
2008/3/31 Tom Tromey <[EMAIL PROTECTED]>: > > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: > > Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll, > Joe> who has just enough technical knowledge to derail conversation. > > I think that if we've reached the point where an SC member feels the > need to post disclaimers about someone's posts, then that someone > ought to simply be banned. > > I know this is extreme, and as far as I know we've never done it > before. But, in my opinion, we've been more than tolerant here. > There's no benefit that I can see to putting up with this kind of bad > behavior. Agreed. I don't mind tolerating abusive behaviour, but this has been going on for a long enough time. Diego.
RE: gcc4.3 configuring problems with mpfr
Hi, I am facing the same problem as mentioned by you. Is there any solution or workaround? Please guide. I have successfully built the mingw native compiler with the following sources, mingw-runtime-3.12 w32api-3.9 binutils-2.17.50-20060824-1-src gcc-3.4.5-20060117-1 I want to build the mingw cross compiler for m32c-elf. The sources used for this cross compiler are as follows: gcc-4.3.0 binutils-2.18 newlib-1.15.0 GCC-4.3.0 requires pre-built GMP and MPFR libraries. I get the following error while configuring the mingw cross compiler for m32c-elf, configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.0+. I have used GMP 4.2.2 and MPFR 2.3.0 sources. I have specified the paths of GMP and MPFR install directories as "--with-gmp=" and "--with-mpfr=". I tried exporting LD_LIBRARY_PATH also, but I still get error during configure. The error is as follows, configure:4542: checking for correct version of mpfr.h configure:4573: i386-pc-mingw32msvc-gcc -o conftest.exe -O2 -I/home/manjunathm1/gmp/prefix/include -I/home/manjunathm1/mpfr/prefix/include conftest.c -L/h ome/manjunathm1/gmp/prefix/lib -L/home/manjunathm1/mpfr/prefix/lib -lmpfr -lgmp >&5 /tmp/cc9dzbXZ.o(.text+0x23):conftest.c: undefined reference to `mpfr_init' /tmp/cc9dzbXZ.o(.text+0x2b):conftest.c: undefined reference to `mpfr_init' /tmp/cc9dzbXZ.o(.text+0x35):conftest.c: undefined reference to `mpfr_atan2' /tmp/cc9dzbXZ.o(.text+0x41):conftest.c: undefined reference to `mpfr_erfc' /tmp/cc9dzbXZ.o(.text+0x4d):conftest.c: undefined reference to `mpfr_subnormalize' Any help on this will be greatly appreciated. Thanks in advance. Regards, Swapna Pawar KPIT Cummins Infosystems Ltd, Pune (INDIA)
Re: wot to do with the Maverick Crunch patches?
On Tue, 1 Apr 2008, Hasjim Williams wrote: > > That illustrates the sort of thing that needs changing to implement > > unwind > > support for a new coprocessor. Obviously you need to get the unwind > > specification in the official ARM EABI documents first before > > implementing > > it in GCC > > Any idea of who to contact and/or how to get this done? Contact Richard Earnshaw in the first instance. > > and binutils will also need to support generating correct > > information given .save directives for the coprocessor registers. > > http://files.futaris.org/gcc/binutils-crunch.patch almost covers this, > but I don't quite follow your binutils patch: > http://sourceware.org/ml/binutils/2006-08/msg00207.html Since my patch fixes a bug specific to the iWMMXt unwind support, you don't need to follow it; either your binutils patch for your coprocessor will be bug-free, or it will have its own bugs you need to debug yourself, unrelated to the iWMMXt one I fixed. Following the current bug-fixed code would be more useful as an example than following old buggy code and a bug-fix to it. > Also, can I assume that running the testsuites (binutils, gcc and glibc) > is the best way to determine what is missing from the current > MaverickCrunch support? You would be well-advised to add an unwind test similar to the one I added in my GCC patch, to make sure that the Crunch registers are restored correctly. That only covers call-preserved registers. Testing call-clobbered registers is harder (but normally unwind information won't be generated for them, so they matter less); for iWMMXt I tried testing using -fcall-saved-wr0 -fcall-saved-wr1 ... but found that CONDITIONAL_REGISTER_USAGE overrides -fcall-saved-* for the wr registers and there is no prologue/epilogue support for saving/restoring wcgr registers. You may need to temporarily modify GCC to save and restore such registers in order to test the unwinding for them. -- Joseph S. Myers [EMAIL PROTECTED]
Re: Thread starvation and resource saturation in atomicity functions?
"Ian Lance Taylor" <[EMAIL PROTECTED]> writes: "Chad Attermann" <[EMAIL PROTECTED]> writes: I can not confirm that it was the i386 code included in the gcc build but it appears that way from the signature. Is this perhaps a problem with the way that gcc 3.4.3 shipping with Solaris 10 x86 was built? Should it have opted for the i486 version instead that does not use spin-locks? Yes, barring the extremely unlikely case that you need to run a plain i386, you should use the i486 code from libstdc++-v3/config/cpu/i486. There are various difficulties with the i386 atomicity code. Fortunately the i486 was released almost 20 years ago, and it's generally safe to use the i486 instructions today. Ian Running at least i486 code would make sense on AMD Opteron processors. I am shocked that the gcc version shipped by Sun Microsystems would be compiled for i386. I compiled my own version of gcc 4.2.2 n the same platform and it too appears to have used i386 code. Perhaps the gcc build configuration process for Solaris is flawed? Regardless I will be attempting to build a new version today that is forced to use the i486 code. Would apprecite if you have any tips. Thanks, Chad.
Fwd: On-line petice proti radaru
...uz jsem podepsala, poslete to taky dal... www.nechciradar.cz Lucka - Original Message - From: "Jan Dvorak" <[EMAIL PROTECTED]> Sent: Monday, March 31, 2008 11:04 AM Subject: Fwd: On-line petice proti radaru Původní zpráva Od: Eva Vaňková Komu: Evička Š.; Bára; Hynek; Ing. Iva Kratochvílová; Ing. Jan Zítek; Jan Dvorak; Lukáš H.; Mgr. Karel Hrubý; Petra Fojtíková; spacekm; Vosík Datum: 30.3.2008 13:26 Předmět: On-line petice proti radaru Ahoj, právě jsem podepsala důležitou online-petici proti americkému radaru v Česku. Potřebujeme tvou pomoc. Tady je odkaz: www.nechciradar.cz Eva Vaňková
Re: wot to do with the Maverick Crunch patches?
> That only covers call-preserved registers. Testing call-clobbered > registers is harder (but normally unwind information won't be generated > for them, so they matter less); for iWMMXt I tried testing using > -fcall-saved-wr0 -fcall-saved-wr1 ... but found that > CONDITIONAL_REGISTER_USAGE overrides -fcall-saved-* for the wr registers > and there is no prologue/epilogue support for saving/restoring wcgr > registers. You may need to temporarily modify GCC to save and restore > such registers in order to test the unwinding for them. Or write testcases by hand in assembly. Paul
RE: GSOC Student application
Diego Novillo wrote on : > 2008/3/31 Tom Tromey <[EMAIL PROTECTED]>: > > > > > > > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: > > > > Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking > > troll, > > There's no benefit that I can see to putting up with this kind of bad > > behavior. > > Agreed. I don't mind tolerating abusive behaviour, but this has been > going on for a long enough time. "Attention-seeking troll", "bad" and "abusive", all seem a bit of a harsh way to describe a hapless victim of mental illness to me. cheers, DaveK -- Can't think of a witty .sigline today
Re: Thread starvation and resource saturation in atomicity functions?
"Chad Attermann" <[EMAIL PROTECTED]> writes: Running at least i486 code would make sense on AMD Opteron processors. I am shocked that the gcc version shipped by Sun Microsystems would be compiled for i386. I compiled my own version of gcc 4.2.2 n the same platform and it too appears to have used i386 code. Perhaps the gcc build configuration process for Solaris is flawed? Regardless I will be attempting to build a new version today that is forced to use the i486 code. Would apprecite if you have any tips. My bad... I was mistakenly thinking I needed re-build gcc in order to get i486 code. In reality I should only need to specify the architecture type when building my own application using "-march=i486", or perhaps even "-march=opteron" in my own case. As stated in gcc docs, i386 is the default instruction set for "i386 and x86-64 family of computers" when the architecture is not explicitly defined, so presumably atomic test-and-set operations will use spin-locks by default. So I suppose the moral of the story remains... excercise extreme caution when using varying thread priorities. Regards.
Re: GSOC Student application
Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll, Joe> who has just enough technical knowledge to derail conversation. I think that if we've reached the point where an SC member feels the need to post disclaimers about someone's posts, then that someone ought to simply be banned. I know this is extreme, and as far as I know we've never done it before. But, in my opinion, we've been more than tolerant here. There's no benefit that I can see to putting up with this kind of bad behavior. The downside of banning J.C. is that if he replies-to-all, no one else would be alerted of his message -- and whoever he replies to (Alexey in this case) may have no clue that he should not pay attention to the message. Paolo
Re: GSOC Student application
Hi, On Mon, 31 Mar 2008, Tom Tromey wrote: > > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: > > Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll, > Joe> who has just enough technical knowledge to derail conversation. > > I think that if we've reached the point where an SC member feels the > need to post disclaimers about someone's posts, then that someone > ought to simply be banned. > > I know this is extreme, and as far as I know we've never done it > before. Actually I think we did it once, in the late 90's (or even early 2000's?). I can't remember that trolls name, but we discussed banning him, and I think we did in the end. Ciao, Michael.
Re: GSOC Student application
> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> "Attention-seeking troll", "bad" and "abusive", all seem a bit Dave> of a harsh way to describe a hapless victim of mental illness to Dave> me. In my message, I purposely described his behavior, not him. I don't know him, I wouldn't presume to guess why he does what he does. Tom
RE: GSOC Student application
Tom Tromey wrote on 01 April 2008 15:34: > > > > > > "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: > > Dave> "Attention-seeking troll", "bad" and "abusive", all seem a bit > Dave> of a harsh way to describe a hapless victim of mental illness to > Dave> me. > > In my message, I purposely described his behavior, not him. I don't > know him, I wouldn't presume to guess why he does what he does. > > Tom Sorry if I misunderstood, I interpreted those descriptions as imputing intent (and malicious intent, at that) to his actions. Of course, I'm reading between the lines rather than speaking from any firsthand knowledge myself. One of my assumptions is that a troll consciously intent on disruption would probably spend more time and effort posting, rather than JC's very haphazard and intermittent 'contributions'. cheers, DaveK -- Can't think of a witty .sigline today
Re: please add DFP to gcc-4.3/changes.html
> I checked in the change to gcc-4.3/changes.html and added a comment > to the PR about other changes we should make to the section about > decimal floating-point support in the GCC Manual. Thanks for the > reminder, I had planned to do this long ago and then forgot all > about it. Thanks, appreciated. -benjamin
RE: GSOC Student application
David Daney wrote on 01 April 2008 17:10: > Does the intent really matter? Well, it certainly has a bearing on how amenable to modification under social pressure his behaviour might or might not be. cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC 4.3 license in manual still under GPLv2
I am now testing a patch for this issue. -- Joseph S. Myers [EMAIL PROTECTED]
Re: GSOC Student application
Dave Korn wrote: David Daney wrote on 01 April 2008 17:10: Does the intent really matter? Well, it certainly has a bearing on how amenable to modification under social pressure his behaviour might or might not be. We have determined this empirically over the course of many months, the result is this e-mail thread. David Daney
Re: GSOC Student application
Dave Korn wrote: Tom Tromey wrote on 01 April 2008 15:34: "Dave" == Dave Korn <[EMAIL PROTECTED]> writes: Dave> "Attention-seeking troll", "bad" and "abusive", all seem a bit Dave> of a harsh way to describe a hapless victim of mental illness to Dave> me. In my message, I purposely described his behavior, not him. I don't know him, I wouldn't presume to guess why he does what he does. Tom Sorry if I misunderstood, I interpreted those descriptions as imputing intent (and malicious intent, at that) to his actions. Of course, I'm reading between the lines rather than speaking from any firsthand knowledge myself. One of my assumptions is that a troll consciously intent on disruption would probably spend more time and effort posting, rather than JC's very haphazard and intermittent 'contributions'. Does the intent really matter? Since it is difficult if not impossible to know the intent, as a practical matter we can only try to manage his actions. David Daney
gcc_contrib bug
we use the following logic: ... : @for f in $? $@; do test -f $$f || exit 0; done; \ echo Touching [EMAIL PROTECTED]; \ touch $@ We have the following chain of dependencies: gcc/configure: gcc/configure.ac gcc/cstamp-h.in: gcc/configure.ac gcc/config.in: gcc/cstamp-h.in In my particular build, for some reason, gcc/cstamp-h.in is missing but the other files are there. I now have four gcc_update tasks running, trying desparately to figure out what to do. It won't touch gcc/cstamp-h.in becuase of the @for line, but it always thinks it needs to update gcc/config.in because gcc/cstamp-h.in is missing. Note that gcc/cstamp-in.h is NOT listed in $?, which is a list of newer prereqs - but not *missing* prereqs. Perhaps we should use $^, which is a list of all prereqs? That leaves us not touching gcc/config.in at all, but at least it doesn't hang. At the very least, some sanity about how many times we permit ourselves to run that Makefile would be useful. I mean, if it doesn't work in the first 345,600 iterations, it's not ever going to work.
Re: How should _Decimal64 and _Decimal128 be aligned on stack?
Hi David, I added gcc mailing list. H.J. On Tue, Apr 1, 2008 at 10:53 AM, Dave Kreitzer <[EMAIL PROTECTED]> wrote: > > > I think we should align _Decimal64 and _Decimal128 to their natural > > alignments when passing a function. The same should apply to x86-64 > > when they are passed on stack. > > > > Rather than aligning _Decimal64 to its natural boundary, I think it is > more sensible to be consistent with the existing 8-byte scalar types, > i.e. double and long long. That would mean aligning _Decimal64 to 4 > bytes within structures and when passing to a function. > That means to change the default alignment of _Decimal64 to 4 bytes in 32bit mode. > For _Decimal128, I agree with the conclusion to align to 16-bytes > within structures and as outgoing arguments. That behavior is > consistent with the existing data types __m128, __m128d, and __m128i. > > Dave Kreitzer > IA-32 and Intel 64 Code Generation > Intel Compiler Lab > > > > --~--~-~--~~~---~--~~ > You received this message because you are subscribed to the Google Groups > "IA32 System V Application Binary Interface" group. > To post to this group, send email to [EMAIL PROTECTED] > To unsubscribe from this group, send email to [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/ia32-abi?hl=en > -~--~~~~--~~--~--~--- > >
m32c build fails
Is this obvious to someone, or should I try to track it down?
[EMAIL PROTECTED] pts/6 ~/m32c/gcc/m32c-elf/m32c-elf/m32cm/libiberty
$ make
if [ x"" != x ]; then \
/greed/dj/m32c/gcc/m32c-elf/./gcc/xgcc
-B/greed/dj/m32c/gcc/m32c-elf/./gcc/ -B/greed/dj/m32c/install/m32c-elf/bin/
-B/greed/dj/m32c/install/m32c-elf/lib/ -isystem
/greed/dj/m32c/install/m32c-elf/include -isystem
/greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c -DHAVE_CONFIG_H -g
-O2 -I. -I../../../../gcc/libiberty/../include -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -pedantic
../../../../gcc/libiberty/cplus-dem.c -o pic/cplus-dem.o; \
else true; fi
/greed/dj/m32c/gcc/m32c-elf/./gcc/xgcc -B/greed/dj/m32c/gcc/m32c-elf/./gcc/
-B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed/dj/m32c/install/m32c-elf/lib/
-isystem /greed/dj/m32c/install/m32c-elf/include -isystem
/greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c -DHAVE_CONFIG_H -g
-O2 -I. -I../../../../gcc/libiberty/../include -W -Wall -Wwrite-strings
-Wc++-compat -Wstrict-prototypes -pedantic
../../../../gcc/libiberty/cplus-dem.c -o cplus-dem.o
../../../../gcc/libiberty/cplus-dem.c: In function
'cplus_demangle_name_to_style':
../../../../gcc/libiberty/cplus-dem.c:807: internal compiler error: in
build2_stat, at tree.c:3107
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [cplus-dem.o] Error 1
[ gdb ] r
GNU C (GCC) version 4.4.0 20080401 (experimental) [trunk revision 133793]
(m32c-elf)
compiled by GNU C version 4.3.0 20071207 (experimental) [trunk revision
130693], GMP version 4.2.2, MPFR version 2.3.0-p2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f08c4b7ee0f32eb95e63bee9a8675368
Breakpoint 1, fancy_abort (file=0x87f32c2 "../../gcc/gcc/tree.c", line=3107,
function=0x87f2e43 "build2_stat")
at ../../gcc/gcc/diagnostic.c:654
654 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
[ gdb ] up
#1 0x085b5c3e in build2_stat (code=PLUS_EXPR, tt=0xb7ddfdd0, arg0=0xb7b43340,
arg1=0xb7aa75e4)
at ../../gcc/gcc/tree.c:3107
3107gcc_assert (TREE_CODE (arg0) == INTEGER_CST || TREE_CODE (arg1) ==
INTEGER_CST);
[ gdb ] call debug_tree(arg0)
unit size
align 8 symtab -1213417700 alias set -1 canonical type 0xb7fc2a28
fields context
pointer_to_this >
sizes-gimplified asm_written public unsigned PSI
size
unit size
align 8 symtab -1213417752 alias set -1 canonical type 0xb7ddfdd0>
arg 0
unit size
align 8 symtab -1208660736 alias set -1 canonical type 0xb7ef4000
precision 16 min max >
var def_stmt
version 1>>
[ gdb ] call debug_tree(arg1)
unit size
align 8 symtab -1213417700 alias set -1 canonical type 0xb7fc2a28
fields context
pointer_to_this >
sizes-gimplified asm_written public unsigned PSI
size
unit size
align 8 symtab -1213417752 alias set -1 canonical type 0xb7ddfdd0>
var def_stmt
version 8>
Re: m32c build fails
It may be related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35781
H.J.
On Tue, Apr 1, 2008 at 12:58 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> Is this obvious to someone, or should I try to track it down?
>
> [EMAIL PROTECTED] pts/6 ~/m32c/gcc/m32c-elf/m32c-elf/m32cm/libiberty
> $ make
> if [ x"" != x ]; then \
> /greed/dj/m32c/gcc/m32c-elf/./gcc/xgcc
> -B/greed/dj/m32c/gcc/m32c-elf/./gcc/ -B/greed/dj/m32c/install/m32c-elf/bin/
> -B/greed/dj/m32c/install/m32c-elf/lib/ -isystem
> /greed/dj/m32c/install/m32c-elf/include -isystem
> /greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c -DHAVE_CONFIG_H
> -g -O2 -I. -I../../../../gcc/libiberty/../include -W -Wall -Wwrite-strings
> -Wc++-compat -Wstrict-prototypes -pedantic
> ../../../../gcc/libiberty/cplus-dem.c -o pic/cplus-dem.o; \
> else true; fi
> /greed/dj/m32c/gcc/m32c-elf/./gcc/xgcc -B/greed/dj/m32c/gcc/m32c-elf/./gcc/
> -B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed/dj/m32c/install/m32c-elf/lib/
> -isystem /greed/dj/m32c/install/m32c-elf/include -isystem
> /greed/dj/m32c/install/m32c-elf/sys-include -mcpu=m32cm -c -DHAVE_CONFIG_H
> -g -O2 -I. -I../../../../gcc/libiberty/../include -W -Wall -Wwrite-strings
> -Wc++-compat -Wstrict-prototypes -pedantic
> ../../../../gcc/libiberty/cplus-dem.c -o cplus-dem.o
> ../../../../gcc/libiberty/cplus-dem.c: In function
> 'cplus_demangle_name_to_style':
> ../../../../gcc/libiberty/cplus-dem.c:807: internal compiler error: in
> build2_stat, at tree.c:3107
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> make: *** [cplus-dem.o] Error 1
>
> [ gdb ] r
> GNU C (GCC) version 4.4.0 20080401 (experimental) [trunk revision 133793]
> (m32c-elf)
> compiled by GNU C version 4.3.0 20071207 (experimental) [trunk
> revision 130693], GMP version 4.2.2, MPFR version 2.3.0-p2.
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> Compiler executable checksum: f08c4b7ee0f32eb95e63bee9a8675368
>
> Breakpoint 1, fancy_abort (file=0x87f32c2 "../../gcc/gcc/tree.c", line=3107,
> function=0x87f2e43 "build2_stat")
> at ../../gcc/gcc/diagnostic.c:654
> 654 internal_error ("in %s, at %s:%d", function, trim_filename (file),
> line);
>
> [ gdb ] up
> #1 0x085b5c3e in build2_stat (code=PLUS_EXPR, tt=0xb7ddfdd0,
> arg0=0xb7b43340, arg1=0xb7aa75e4)
> at ../../gcc/gcc/tree.c:3107
> 3107gcc_assert (TREE_CODE (arg0) == INTEGER_CST || TREE_CODE (arg1)
> == INTEGER_CST);
>
> [ gdb ] call debug_tree(arg0)
>type type BLK
> size
> unit size
> align 8 symtab -1213417700 alias set -1 canonical type 0xb7fc2a28
> fields context
>
> pointer_to_this >
> sizes-gimplified asm_written public unsigned PSI
> size
> unit size
> align 8 symtab -1213417752 alias set -1 canonical type 0xb7ddfdd0>
>
> arg 0 type size
> unit size
> align 8 symtab -1208660736 alias set -1 canonical type 0xb7ef4000
> precision 16 min max >
> var def_stmt 0xb7f08d20>
> version 1>>
>
> [ gdb ] call debug_tree(arg1)
>type type BLK
> size
> unit size
> align 8 symtab -1213417700 alias set -1 canonical type 0xb7fc2a28
> fields context
>
> pointer_to_this >
> sizes-gimplified asm_written public unsigned PSI
> size
> unit size
> align 8 symtab -1213417752 alias set -1 canonical type 0xb7ddfdd0>
> var def_stmt
> version 8>
>
>
Re: m32c build fails
Sent from my iPhone
On Apr 1, 2008, at 13:06, "H.J. Lu" <[EMAIL PROTECTED]> wrote:
It may be related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35781
It is not. It is a pointer plus issue. Can you show the full backtrace?
-- Pinski
H.J.
On Tue, Apr 1, 2008 at 12:58 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
Is this obvious to someone, or should I try to track it down?
[EMAIL PROTECTED] pts/6 ~/m32c/gcc/m32c-elf/m32c-elf/m32cm/libiberty
$ make
if [ x"" != x ]; then \
/greed/dj/m32c/gcc/m32c-elf/./gcc/xgcc -B/greed/dj/m32c/
gcc/m32c-elf/./gcc/ -B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed/
dj/m32c/install/m32c-elf/lib/ -isystem /greed/dj/m32c/install/m32c-
elf/include -isystem /greed/dj/m32c/install/m32c-elf/sys-include -
mcpu=m32cm -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../../gcc/
libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -
Wstrict-prototypes -pedantic ../../../../gcc/libiberty/cplus-
dem.c -o pic/cplus-dem.o; \
else true; fi
/greed/dj/m32c/gcc/m32c-elf/./gcc/xgcc -B/greed/dj/m32c/gcc/m32c-
elf/./gcc/ -B/greed/dj/m32c/install/m32c-elf/bin/ -B/greed/dj/m32c/
install/m32c-elf/lib/ -isystem /greed/dj/m32c/install/m32c-elf/
include -isystem /greed/dj/m32c/install/m32c-elf/sys-include -
mcpu=m32cm -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../../gcc/
libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -
Wstrict-prototypes -pedantic ../../../../gcc/libiberty/cplus-dem.c
-o cplus-dem.o
../../../../gcc/libiberty/cplus-dem.c: In function
'cplus_demangle_name_to_style':
../../../../gcc/libiberty/cplus-dem.c:807: internal compiler error:
in build2_stat, at tree.c:3107
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [cplus-dem.o] Error 1
[ gdb ] r
GNU C (GCC) version 4.4.0 20080401 (experimental) [trunk revision
133793] (m32c-elf)
compiled by GNU C version 4.3.0 20071207 (experimental)
[trunk revision 130693], GMP version 4.2.2, MPFR version 2.3.0-p2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-
heapsize=4096
Compiler executable checksum: f08c4b7ee0f32eb95e63bee9a8675368
Breakpoint 1, fancy_abort (file=0x87f32c2 "../../gcc/gcc/tree.c",
line=3107, function=0x87f2e43 "build2_stat")
at ../../gcc/gcc/diagnostic.c:654
654 internal_error ("in %s, at %s:%d", function,
trim_filename (file), line);
[ gdb ] up
#1 0x085b5c3e in build2_stat (code=PLUS_EXPR, tt=0xb7ddfdd0,
arg0=0xb7b43340, arg1=0xb7aa75e4)
at ../../gcc/gcc/tree.c:3107
3107gcc_assert (TREE_CODE (arg0) == INTEGER_CST ||
TREE_CODE (arg1) == INTEGER_CST);
[ gdb ] call debug_tree(arg0)
type tree_1 type_0 BLK
size
unit size
align 8 symtab -1213417700 alias set -1 canonical type
0xb7fc2a28 fields
context
pointer_to_this >
sizes-gimplified asm_written public unsigned PSI
size
unit size
align 8 symtab -1213417752 alias set -1 canonical type
0xb7ddfdd0>
arg 0type sizetype HI
size
unit size
align 8 symtab -1208660736 alias set -1 canonical type
0xb7ef4000 precision 16 min max
>
var def_stmt
version 1>>
[ gdb ] call debug_tree(arg1)
type tree_1 type_0 BLK
size
unit size
align 8 symtab -1213417700 alias set -1 canonical type
0xb7fc2a28 fields
context
pointer_to_this >
sizes-gimplified asm_written public unsigned PSI
size
unit size
align 8 symtab -1213417752 alias set -1 canonical type
0xb7ddfdd0>
var def_stmt 0xb7fba5b0>
version 8>
Re: m32c build fails
#0 fancy_abort (file=0x87f32c2 "../../gcc/gcc/tree.c", line=3107, function=0x87f2e43 "build2_stat") at ../../gcc/gcc/diagnostic.c:654 #1 0x085b5c3e in build2_stat (code=PLUS_EXPR, tt=0xb7db5dd0, arg0=0xb7b19340, arg1=0xb7a7d5e4) at ../../gcc/gcc/tree.c:3107 #2 0x0822501e in fold_binary (code=PLUS_EXPR, type=0xb7db5dd0, op0=0xb7a7d5e4, op1=0xb7b19340) at ../../gcc/gcc/fold-const.c:9221 #3 0x08247ba2 in fold_build2_stat (code=PLUS_EXPR, type=0xb7db5dd0, op0=0xb7a7d5e4, op1=0xb7b19340) at ../../gcc/gcc/fold-const.c:13397 #4 0x0848b098 in create_mem_ref (bsi=0xbfb6b6a0, type=0xb7f9, addr=0xbfb6b62c) at ../../gcc/gcc/tree-ssa-address.c:641 #5 0x084de416 in rewrite_uses (data=0xbfb6b7e0) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5227 #6 0x084e4252 in tree_ssa_iv_optimize_loop (data=0xbfb6b7e0, loop=) at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5485 #7 0x084e47bf in tree_ssa_iv_optimize () at ../../gcc/gcc/tree-ssa-loop-ivopts.c:5518 #8 0x084f29e5 in tree_ssa_loop_ivopts () at ../../gcc/gcc/tree-ssa-loop.c:580 #9 0x08313c6f in execute_one_pass (pass=0x8837e60) at ../../gcc/gcc/passes.c:1127 #10 0x08313e77 in execute_pass_list (pass=0x8837e60) at ../../gcc/gcc/passes.c:1180 #11 0x08313e8a in execute_pass_list (pass=0x8837aa0) at ../../gcc/gcc/passes.c:1181 #12 0x08313e8a in execute_pass_list (pass=0x88372e0) at ../../gcc/gcc/passes.c:1181 #13 0x084483ed in tree_rest_of_compilation (fndecl=0xb7f95700) at ../../gcc/gcc/tree-optimize.c:420 #14 0x085f65f8 in cgraph_expand_function (node=0xb7ebb800) at ../../gcc/gcc/cgraphunit.c:1157 #15 0x085f9367 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1220 #16 0x0805f07e in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8065 #17 0x083dac0b in toplev_main (argc=20, argv=0xbfb6ba44) at ../../gcc/gcc/toplev.c:971 #18 0x080e0a02 in main (argc=144, argv=0x0) at ../../gcc/gcc/main.c:35
Re: GSOC Student application
On Tue, Apr 01, 2008 at 05:09:32PM +0200, Michael Matz wrote: > Hi, > > On Mon, 31 Mar 2008, Tom Tromey wrote: > > > > "Joe" == Joe Buck <[EMAIL PROTECTED]> writes: > > > > Joe> It's best to ignore J.C. Pizarro. He's an attention-seeking troll, > > Joe> who has just enough technical knowledge to derail conversation. > > > > I think that if we've reached the point where an SC member feels the > > need to post disclaimers about someone's posts, then that someone > > ought to simply be banned. > > > > I know this is extreme, and as far as I know we've never done it > > before. > > Actually I think we did it once, in the late 90's (or even early 2000's?). > I can't remember that trolls name, but we discussed banning him, and I > think we did in the end. Yes, we banned one person in the late 1990s. But that guy wasn't just your average troll; he threatened violence against several developers and even threw in "I know where you live" at one point.
memory leak on regular expression (regex.c)
Hello,
I found a memory leak on regcomp function - gcc-4.4.2 (i used Memory validator
tool to confirm it) .
On regcomp this line if (re_compile_fastmap (preg) == -2)
is the cause to the memory leak (it calls to re_compile_fastmap function that
allocates memory that is not release)
The code of my program to see the memory leak is:
int main() {
for (size_t i=0; i<100; ++i) {
std::string text("a");;
static const int MAX_PARTS = 10;
static const int flags = REG_EXTENDED;
regex_t _compiled;
regmatch_t _sub[MAX_PARTS];
int res = regcomp(&_compiled, "a", flags);
bool matched = (regexec(&_compiled, text.c_str(), MAX_PARTS, _sub, 0) !=
REG_NOMATCH);
regfree(&_compiled);
}
return 0;
Is there a bug fix to it?
Thanks,
Amihud
You rock. That's why Blockbuster's offering you one month of Blockbuster Total
Access, No Cost.
http://tc.deals.yahoo.com/tc/blockbuster/text5.com
Re: gcc4.3 configuring problems with mpfr
Swapna Pawar wrote: configure:4542: checking for correct version of mpfr.h configure:4573: i386-pc-mingw32msvc-gcc -o conftest.exe -O2 -I/home/manjunathm1/gmp/prefix/include -I/home/manjunathm1/mpfr/prefix/include conftest.c -L/h ome/manjunathm1/gmp/prefix/lib -L/home/manjunathm1/mpfr/prefix/lib -lmpfr -lgmp >&5 /tmp/cc9dzbXZ.o(.text+0x23):conftest.c: undefined reference to `mpfr_init' Are the -I and -L options correct? Run the command by hand with --save-temps and look at the .i file and verify that the right header files got included. Run the command by hand with -Wl,--verbose and verify that the right libraries got linked in. Look at the installed libraries and make sure that they contain the functions in question, i.e. make sure that they were built and installed correctly. Maybe try installing gmp and mpfr in the same place instead of in two different places? Jim
