From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zack Weinberg To: Alexandre Oliva Cc: gcc-bugs@gcc.gnu.org Subject: Re: bug report Date: Tue, 27 Jun 2000 11:25:00 -0000 Message-id: <20000627112505.W279@wolery.cumb.org> References: <20000627054811.G23854@Jeffreys.suse.de> <20000626205156.R279@wolery.cumb.org> X-SW-Source: 2000-06/msg00664.html List-Id: On Tue, Jun 27, 2000 at 03:17:47PM -0300, Alexandre Oliva wrote: > On Jun 27, 2000, Zack Weinberg wrote: > > > And it should be more enthusiastic about the alternative of posting a > > URL. > > Nope. Downloading large files is not a reasonable option for me, for > example. I'd much rather have them dropped interactively in my > mailbox. Not quite what I meant. First choice should still be to include the .i file in the bug report. But what happens nowadays is that someone sees their .i file is too big for the mailing list, so they say "mail me privately". I'd much rather get an URL than that. zw >>From espie@schutzenberger.liafa.jussieu.fr Tue Jun 27 12:02:00 2000 From: Marc Espie To: gcc-patches@gcc.gnu.org Cc: gcc-bugs@gcc.gnu.org Subject: [PATCH] dwarf2out.c breakage on ss2000-06-26 Date: Tue, 27 Jun 2000 12:02:00 -0000 Message-id: <20000627210226.A18770@schutzenberger.liafa.jussieu.fr> X-SW-Source: 2000-06/msg00665.html Content-length: 948 Recent changes to dwarf2out.c broke OpenBSD, and probably a lot of other platforms as well (most platforms that define DWARF2_UNWIND_INFO 0). If UNALIGNED_INT_ASM_OP is unavailable, dwarf2out.c does not provide a suitable definition for ASM_OUTPUT_DWARF_DATA2, even though it uses it. The following patch restores OpenBSD to sanity. Tue Jun 27 20:59:01 CEST 2000 Marc Espie * dwarf2out.c (ASM_OUTPUT_DWARF_DATA2): provide in the case where UNALIGNED_INT_ASM_OP is unavailable. --- gcc/dwarf2out.c.orig Tue Jun 27 20:41:23 2000 +++ gcc/dwarf2out.c Tue Jun 27 20:45:26 2000 @@ -494,6 +494,9 @@ static void def_cfa_1 PARAMS ((const #define ASM_OUTPUT_DWARF_DELTA(FILE,LABEL1,LABEL2) \ ASM_OUTPUT_DWARF_DELTA4 (FILE,LABEL1,LABEL2) +#define ASM_OUTPUT_DWARF_DATA2(FILE,VALUE) \ + assemble_integer (GEN_INT (VALUE), 2, 1) + #define ASM_OUTPUT_DWARF_DATA4(FILE,VALUE) \ assemble_integer (GEN_INT (VALUE), 4, 1) >>From lucier@math.purdue.edu Tue Jun 27 12:13:00 2000 From: Brad Lucier To: gcc-help@gcc.gnu.org, gcc-bugs@gcc.gnu.org Cc: lucier@math.purdue.edu Subject: difficulties debugging code Date: Tue, 27 Jun 2000 12:13:00 -0000 Message-id: <200006271913.OAA05805@polya.math.purdue.edu> X-SW-Source: 2000-06/msg00666.html Content-length: 2479 I don't know if this is a bug or whether I need help, so I'm asking both lists. I'm trying to debug some code compiled with gcc-2.96-20000624 on alphaev6-unknown-linux-gnu with options gcc -fno-math-errno -mieee -mcpu=ev6 -Wall -W -O1 -save-temps -g -c ... and linked with gcc -g -mieee -rdynamic ... I'm using gdb 4.17.0.11. Everything is fine until I try to step through the following code: void ___setup (___setup_params_struct *setup_params) { ___processor_state ___ps; ___mod_or_lnk mol; int i; if (setup_params == 0 || setup_params->version_major != 21) return; if (setup_state != 0) return; setup_state = 2; ___setup_params = *setup_params; // <<<<<<<<<<<<<<<<<<<<<<<<< ... Then I get a segmentation fault with the following message: (gdb) s Program received signal SIGSEGV, Segmentation fault. warning: Hit beginning of text section without finding warning: enclosing function for address 0xc39fff54 This warning occurs if you are debugging a function without any symbols (for example, in a stripped executable). In that case, you may wish to increase the size of the search with the `set heuristic-fence-post' command. Otherwise, you told GDB there was a function where there isn't one, or (more likely) you have encountered a bug in GDB. 0xc39fff54 in ?? () (gdb) up #1 0x120043b00 in ___setup (setup_params=0x11ffff720) at setup.c:1415 1415 ___setup_params = *setup_params; (gdb) print *setup_params $1 = {version_major = 21, version_minor = 0, argc = 1, argv = 0x11ffff868, min_heap = 0, max_heap = 0, live_percent = 0, gc_hook = 0, fatal_error = 0, standard = 0, debug_level = 0, default_io_encoding = 1, force_tty = 0, force_unbuffered_io = 0, linker = 0x120041410 <____20_gsi__>, event_get = 0, event_handler = 0, dummy1 = 0, dummy2 = 0, dummy3 = 0, dummy4 = 0, dummy5 = 0, dummy6 = 0, dummy7 = 0, dummy8 = 0} So *setup_params seems perfectly fine. The assembly code at this point is $LM658: .stabn 68,0,1415,$LM658 lda $16,___setup_params lda $18,176 jsr $26,memcpy ldgp $29,0($26) The real bug I'm trying to track down is a little farther along in the execution path, so I'm just getting frustrated playing with this part of the code. So, do any of you have any ideas? If I set a breakpoint after this point in the code and start stepping from there, it just segfaults in some other place (where there really isn't a problem, either). I haven't seen this type of behavior before. Brad Lucier >>From dave@hiauly1.hia.nrc.ca Tue Jun 27 12:51:00 2000 From: "John David Anglin" To: dave@hiauly1.hia.nrc.ca (John David Anglin) Cc: gcc-bugs@gcc.gnu.org Subject: Re: Miscellaneous testsuitsuite failures under hpux 10.20 Date: Tue, 27 Jun 2000 12:51:00 -0000 Message-id: <200006271951.PAA04221@hiauly1.hia.nrc.ca> References: <200006232114.RAA13066@hiauly1.hia.nrc.ca> X-SW-Source: 2000-06/msg00667.html Content-length: 665 > struct foo { > void *entry[40]; > } __attribute__ ((aligned(32))); > > This gives a value of 256 for rli->offset_align. The bit field for The value of 256 for rli->offset_align doesn't seem to make sense. It looks like the compiler is applying __attribute__ to entry as well as foo. The current design limits the alignment of field declarations to values that can be contained in 8 bits. Is this big enough for all reasonable purposes? Obviously, larger alignments may be needed for other types. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) >>From vonbrand@inf.utfsm.cl Tue Jun 27 12:53:00 2000 From: Horst von Brand To: Philipp Thomas , gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: bootstrap fails: msgfmt: Not found Date: Tue, 27 Jun 2000 12:53:00 -0000 Message-id: <200006271954.e5RJs2J18693@pincoya.inf.utfsm.cl> References: <20000627171632.N13023@Jeffreys.suse.de> X-SW-Source: 2000-06/msg00668.html Content-length: 586 Here (Alpha, Red Hat 6.1, CVS from earlier today) I'm getting: make[3]: Entering directory `/h/redhat/BUILD/GCC/build-gcc-20000627/gcc/po' file=`echo en_GB | sed 's,.*/,,'`.gmo \ && rm -f $file && PATH=../src:$PATH no -o $file /mnt/pincoya/build/GCC/gcc/gcc/po/en_GB.po /bin/sh: no: command not found -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 >>From aoliva@redhat.com Tue Jun 27 12:57:00 2000 From: Alexandre Oliva To: Zack Weinberg Cc: gcc-bugs@gcc.gnu.org Subject: Re: bug report Date: Tue, 27 Jun 2000 12:57:00 -0000 Message-id: References: <20000627054811.G23854@Jeffreys.suse.de> <20000626205156.R279@wolery.cumb.org> <20000627112505.W279@wolery.cumb.org> X-SW-Source: 2000-06/msg00669.html Content-length: 684 On Jun 27, 2000, Zack Weinberg wrote: > First choice should still be to include the .i file in the bug > report. But what happens nowadays is that someone sees their .i > file is too big for the mailing list, so they say "mail me > privately". I'd much rather get an URL than that. I see. I agree. A patch for the bug reporting instructions will be appreciated :-) -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{cygnus.com, redhat.com} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist *Please* write to mailing lists, not to me