[Bug c/25636] New: cc1 and cc1plus --help core

[Bug c/25636] New: cc1 and cc1plus --help core

[freddyz77 at tin dot it]

I just downloaded and compiled gcc-4.2-20051231 with 

  ./configure --prefix=/opt/gcc42
  make
  make install (root)

after setting LD_LIBRARY_PATH to /opt/gcc42/lib

$ /opt/gcc42/bin/gcc --version
gcc (GCC) 4.2.0 20051231 (experimental)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ /opt/gcc42/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/opt/gcc42
Thread model: posix
gcc version 4.2.0 20051231 (experimental)

$ /opt/gcc42/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 --help
The following options are language-independent:

cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
$ /opt/gcc42/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1plus --help
The following options are language-independent:

cc1plus: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

>From gdb

$ gdb /opt/gcc42/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1
GNU gdb Red Hat Linux (6.3.0.0-1.84rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) r --help
Starting program: /opt/gcc42/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 --help
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x82f000
The following options are language-independent:


Program received signal SIGSEGV, Segmentation fault.
0x083580bd in print_filtered_help (flag=536870912) at ../.././gcc/opts.c:1301
1301          memset (printed, 0, cl_options_count);
(gdb) bt
#0  0x083580bd in print_filtered_help (flag=536870912) at
../.././gcc/opts.c:1301
#1  0x08358f53 in decode_options (argc=2, argv=0xbf830644) at
../.././gcc/opts.c:1250
#2  0x083bf9b0 in toplev_main (argc=2, argv=0xbf830644) at
../.././gcc/toplev.c:1974
#3  0x080b8e6f in main (argc=0, argv=0x259) at ../.././gcc/main.c:35

I'm using Fedore Core 4 with all updates

bye
  freddy77


-- 
           Summary: cc1 and cc1plus --help core
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: freddyz77 at tin dot it
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-01-02 16:44 -------
I cannot reproduce this on either powerpc-darwin or x86_64-linux-gnu.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[freddyz77 at tin dot it]

------- Comment #2 from freddyz77 at tin dot it  2006-01-06 09:14 -------
Well, I don't know why but looking more deeply I still don't understand

$ gdb /opt/gcc42/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1
GNU gdb Red Hat Linux (6.3.0.0-1.84rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".

(gdb) r --help
Starting program: /opt/gcc42/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 --help
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xb9f000
The following options are language-independent:


Program received signal SIGSEGV, Segmentation fault.
0x083580bd in print_filtered_help (flag=536870912) at ../.././gcc/opts.c:1301
1301          memset (printed, 0, cl_options_count);
(gdb) list
1296      if (flag == CL_COMMON || flag == CL_TARGET)
1297        {
1298          filter = flag;
1299          if (!printed)
1300            printed = xmalloc (cl_options_count);
1301          memset (printed, 0, cl_options_count);
1302        }
1303      else
1304        {
1305          /* Don't print COMMON options twice.  */
(gdb) info registers
eax            0x9aeb988        162445704
ecx            0x9aeb980        162445696
edx            0x0      0
ebx            0x24e    590
esp            0xbfbaa5b0       0xbfbaa5b0
ebp            0xbfbab9a0       0xbfbab9a0
esi            0x0      0
edi            0x20400001       541065217
eip            0x83580bd        0x83580bd
eflags         0x10246  66118
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb) disas 0x83580bd
Dump of assembler code for function print_filtered_help:
0x08357f40 <print_filtered_help+0>:     push   %ebp
0x08357f41 <print_filtered_help+1>:     push   %edi
0x08357f42 <print_filtered_help+2>:     push   %esi
0x08357f43 <print_filtered_help+3>:     push   %ebx
...
0x083580aa <print_filtered_help+362>:   je     0x83581a5
<print_filtered_help+613>
0x083580b0 <print_filtered_help+368>:   mov    0x85a641c,%ebx
0x083580b6 <print_filtered_help+374>:   mov    0x85f5940,%eax
0x083580bb <print_filtered_help+379>:   xor    %edx,%edx
0x083580bd <print_filtered_help+381>:   mov    %ebx,0x85a641c
0x083580c3 <print_filtered_help+387>:   mov    %ebx,0x8(%esp)
0x083580c7 <print_filtered_help+391>:   mov    %edx,0x4(%esp)
0x083580cb <print_filtered_help+395>:   mov    %eax,(%esp)
0x083580ce <print_filtered_help+398>:   call   0x8049afc
0x083580d3 <print_filtered_help+403>:   test   %ebx,%ebx
0x083580d5 <print_filtered_help+405>:   je     0x8358081
<print_filtered_help+321>
0x083580d7 <print_filtered_help+407>:   mov    0x10(%esp),%edx
0x083580db <print_filtered_help+411>:   mov    %edx,0x14(%esp)
0x083580df <print_filtered_help+415>:   xor    %esi,%esi
0x083580e1 <print_filtered_help+417>:   xor    %ebx,%ebx
0x083580e3 <print_filtered_help+419>:   jmp    0x83580f1
<print_filtered_help+433>
0x083580e5 <print_filtered_help+421>:   inc    %esi
0x083580e6 <print_filtered_help+422>:   add    $0x1c,%ebx
0x083580e9 <print_filtered_help+425>:   cmp    0x85a641c,%esi
0x083580ef <print_filtered_help+431>:   je     0x8358081
<print_filtered_help+321>
0x083580f1 <print_filtered_help+433>:   mov    0x85a642c(%ebx),%edx
0x083580f7 <print_filtered_help+439>:   mov    0x14(%esp),%eax
...
0x0835814e <print_filtered_help+526>:   call   0x804955c
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) x/4b 0x85a641c
0x85a641c <cl_options_count>:   0x4e    0x02    0x00    0x00
(gdb)

The program stop at memset so why this 

  mov    %ebx,0x85a641c

should happen??? I cannot find any assigment to this variable however assembly
write into this variable...

freddy77


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-01-16 00:51 -------
*** Bug 25800 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drab at kepler dot fjfi dot
                   |                            |cvut dot cz


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-01-16 00:54 -------
This does make sense as printed is set right before the memset if was NULL. 
Can you use "make bootstrap" instead?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #5 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 01:24 -------
(In reply to comment #1)
> I cannot reproduce this on either powerpc-darwin or x86_64-linux-gnu.

Confirmed here, irreproducible on x86_64, but occures on plain 32-bit x86.

Just in case LANG* or LC_* has to do anything with it, I use UTF-8. But in both
cases (x86 and x86_64)!

$ set|grep LC
LC_ADDRESS=cs_CZ.UTF-8
LC_COLLATE=en_US.UTF-8
LC_CTYPE=en_US.UTF-8
LC_IDENTIFICATION=cs_CZ.UTF-8
LC_MEASUREMENT=cs_CZ.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_MONETARY=cs_CZ.UTF-8
LC_NAME=cs_CZ.UTF-8
LC_NUMERIC=cs_CZ.UTF-8
LC_PAPER=cs_CZ.UTF-8
LC_SOURCED=1
LC_TELEPHONE=cs_CZ.UTF-8
LC_TIME=en_US.UTF-8
$ set|grep LANG
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8:en_US:en


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #6 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 01:33 -------
(In reply to comment #2)
> Program received signal SIGSEGV, Segmentation fault.
> 0x083580bd in print_filtered_help (flag=536870912) at ../.././gcc/opts.c:1301
> 1301          memset (printed, 0, cl_options_count);
> (gdb) list
> 1296      if (flag == CL_COMMON || flag == CL_TARGET)
> 1297        {
> 1298          filter = flag;
> 1299          if (!printed)
> 1300            printed = xmalloc (cl_options_count);
> 1301          memset (printed, 0, cl_options_count);

This may be a problem in case when 'printed' is previously allocated to some
size that is less than the one that is given by the current 'cl_options_count'.
So perhaps this should rather be something like:

printed = xrealloc (printed, cl_options_count);
memset (printed, 0, cl_options_count);

That is if there is anything like 'xrealloc' (I didn't check), but you get the
idea. This should be safe, right?

(And BTW, I allways use "make bootstrap" with 3-stage compilation and the
result is the same, so that isn't the issue.)

> 1302        }
> ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #7 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 01:38 -------
(In reply to comment #6)
> (In reply to comment #2)
...
> So perhaps this should rather be something like:
> 
> printed = xrealloc (printed, cl_options_count);
> memset (printed, 0, cl_options_count);

Or perhaps:

xfree (!printed);
printed = xmalloc (cl_options_count);
memset (printed, 0, cl_options_count);

In case there is no 'xrealloc'. ;)

Or are we absolutely sure, that if the 'printed' is non-NULL, that then it
points to the space of at least 'cl_options_count' size?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2006-01-16 01:40 -------
cl_options_count does not change.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #9 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 01:48 -------
OK, so how about this, couldn't this be an issue?

--- opts.c.old  2006-01-15 23:36:53.000000000 +0100
+++ opts.c      2006-01-16 02:48:17.000000000 +0100
@@ -1291,7 +1291,7 @@ print_filtered_help (unsigned int flag)
   unsigned int i, len, filter, indent = 0;
   bool duplicates = false;
   const char *help, *opt, *tab;
-  static char *printed;
+  static char *printed = NULL;

   if (flag == CL_COMMON || flag == CL_TARGET)
     {


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[pinskia at physics dot uc dot edu]

------- Comment #10 from pinskia at gcc dot gnu dot org  2006-01-16 01:50 -------
Subject: Re:  cc1 and cc1plus --help core


On Jan 15, 2006, at 8:48 PM, drab at kepler dot fjfi dot cvut dot cz 
wrote:

>
>
> ------- Comment #9 from drab at kepler dot fjfi dot cvut dot cz  
> 2006-01-16 01:48 -------
> OK, so how about this, couldn't this be an issue?
>
> --- opts.c.old  2006-01-15 23:36:53.000000000 +0100
> +++ opts.c      2006-01-16 02:48:17.000000000 +0100
> @@ -1291,7 +1291,7 @@ print_filtered_help (unsigned int flag)
>    unsigned int i, len, filter, indent = 0;
>    bool duplicates = false;
>    const char *help, *opt, *tab;
> -  static char *printed;
> +  static char *printed = NULL;
>

No because static variables are initialized to 0 by default by the C 
standard.

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

Re: [Bug middle-end/25636] cc1 and cc1plus --help core

[Andrew Pinski]

On Jan 15, 2006, at 8:48 PM, drab at kepler dot fjfi dot cvut dot cz 
wrote:

>
>
> ------- Comment #9 from drab at kepler dot fjfi dot cvut dot cz  
> 2006-01-16 01:48 -------
> OK, so how about this, couldn't this be an issue?
>
> --- opts.c.old  2006-01-15 23:36:53.000000000 +0100
> +++ opts.c      2006-01-16 02:48:17.000000000 +0100
> @@ -1291,7 +1291,7 @@ print_filtered_help (unsigned int flag)
>    unsigned int i, len, filter, indent = 0;
>    bool duplicates = false;
>    const char *help, *opt, *tab;
> -  static char *printed;
> +  static char *printed = NULL;
>

No because static variables are initialized to 0 by default by the C 
standard.

-- Pinski

[Bug middle-end/25636] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #11 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 02:02 -------
OK, now, this is totally weird, because now I checked the 'stage1-cc/cc1'
within the output object compilation tree and it works OK. However the higher
stages 'prev-gcc/cc1' and 'gcc/cc1' fail! I also notice that while the latter
two are about 16 MB in size, the former one is 18 MB. This would indicate, that
there is less (if any) optimizations applied during the first stage compilation
(which is understandable) than in the second and third stage. And this would
indicate, that there is some other bug somewhere in those options, that are
disabled during the first stage and enabled during the second and third. (Note
that this happens even when I compiled the compiler with itself, so this is not
a thing of compiling the first stage with a different compiler or version.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #12 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 02:09 -------
>From compilation logs, I see:

------------------
gcc -c   -g -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute    -DHAVE_CONFIG_H -I. -I.
-I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc
-I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/.
-I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/../include
-I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/../libcpp/include 
-I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/../libdecnumber
-I../libdecnumber    ../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/opts.c
-o opts.o
------------------------

and

------------------------
/usr/local/opt/MDLinux/builds/gcc-SVN-20060113/AthlonXP-big/gcc-SVN-20060113/./prev-gcc/xgcc
-B/usr/local/opt/MDLinux/builds/gcc-SVN-20060113/AthlonXP-big/gcc-SVN-20060113/./prev-gcc/
-B/usr/local/opt/gcc-4.2/i786-pc-linux-gnu/bin/ -c   -O2 -g
-fomit-frame-pointer -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute -Werror    -DHAVE_CONFIG_H
-I. -I. -I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc
-I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/.
-I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/../include
-I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/../libcpp/include 
-I../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/../libdecnumber
-I../libdecnumber    ../../../../gcc-SVN-20060113/gcc-SVN-20060113/gcc/opts.c
-o opts.o
------------------------

Which is basically "no opts" against "-O2 -fomit-frame-pointer". So it should
be in some option wrapped within the -O2, I guess.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #13 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 02:51 -------
This is how the (relevant) thing looks like, when compiled with -O2
-fomit-frame-pointer. I removed the "static" modifier of the function, since
then it got merged within other functions and didn't get its own instance, but
the failure is still there.

------------------------------
        .p2align 4,,15
        .type   print_filtered_help, @function
print_filtered_help:
.LFB197:
        .loc 1 1290 0
.LVL93:
        pushl   %ebp
.LCFI22:
        pushl   %edi
.LCFI23:
        pushl   %esi
.LCFI24:
        pushl   %ebx
.LCFI25:
        subl    $28, %esp
.LCFI26:
        .loc 1 1296 0
        cmpl    $536870912, %eax
        sete    %dl
        cmpl    $4194304, %eax
        .loc 1 1290 0
        movl    %eax, 16(%esp)
        .loc 1 1296 0
        sete    %al
.LVL94:
        orb     %al, %dl
        je      .L155
        .loc 1 1299 0
        movl    printed.20731, %eax
        testl   %eax, %eax
        je      .L211
        movl    cl_options_count, %ebx
.L157:
        .loc 1 1301 0
        movl    printed.20731, %eax
        movl    %ebx, cl_options_count
.LBB59:
.LBB60:
        .file 3 "/usr/include/bits/stdio.h"
        .loc 3 94 0
        xorl    %esi, %esi
.LVL95:
.LBE60:
.LBE59:
        .loc 1 1301 0
        movl    %ebx, 8(%esp)
        movl    $0, 4(%esp)
.LBB61:
.LBB62:
        .loc 3 94 0
        xorl    %ebx, %ebx
.LBE62:
.LBE61:
        .loc 1 1301 0
        movl    %eax, (%esp)
        call    memset

...

.L211:
        .loc 1 1300 0
        movl    cl_options_count, %ebx
        movl    %ebx, (%esp)
        call    xmalloc
        movl    %eax, printed.20731
        jmp     .L157

...
------------------------------


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2006-01-16 02:55 -------
I can reproduce this now after building on x86.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug middle-end/25636] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #15 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 03:02 -------
(In reply to comment #13)
> This is how the (relevant) thing looks like, when compiled with -O2
> -fomit-frame-pointer. I removed the "static" modifier of the function, since
> then it got merged within other functions and didn't get its own instance, but
> the failure is still there.
> 
> ------------------------------
>         .p2align 4,,15
>         .type   print_filtered_help, @function
> print_filtered_help:
> .LFB197:
>         .loc 1 1290 0
> .LVL93:
>         pushl   %ebp
> .LCFI22:
>         pushl   %edi
> .LCFI23:
>         pushl   %esi
> .LCFI24:
>         pushl   %ebx
> .LCFI25:
>         subl    $28, %esp
> .LCFI26:
>         .loc 1 1296 0
>         cmpl    $536870912, %eax
>         sete    %dl
>         cmpl    $4194304, %eax
>         .loc 1 1290 0
>         movl    %eax, 16(%esp)
>         .loc 1 1296 0
>         sete    %al
> .LVL94:
>         orb     %al, %dl
>         je      .L155
>         .loc 1 1299 0
>         movl    printed.20731, %eax
>         testl   %eax, %eax
>         je      .L211
>         movl    cl_options_count, %ebx
> .L157:
>         .loc 1 1301 0
>         movl    printed.20731, %eax
>         movl    %ebx, cl_options_count
> .LBB59:
> .LBB60:
>         .file 3 "/usr/include/bits/stdio.h"
>         .loc 3 94 0
>         xorl    %esi, %esi
> .LVL95:
> .LBE60:
> .LBE59:
>         .loc 1 1301 0
>         movl    %ebx, 8(%esp)
>         movl    $0, 4(%esp)
> .LBB61:
> .LBB62:
>         .loc 3 94 0
>         xorl    %ebx, %ebx
> .LBE62:
> .LBE61:
>         .loc 1 1301 0
>         movl    %eax, (%esp)
>         call    memset

I guess the third parameter isn't set at all! Is it supposed to be %ecx or what
is supposed to be the third register parameter of the memset call? Anyway, it
should be set to the 'cl_options_count', but you may notice, that
'cl_options_count' resides in %ebx all the time, and just before the call to
the 'memset' function there is a 'xorl %ebx, %ebx', which is perhaps correct as
it is the second argument of the 'memset' and that should be 0. But the third
argument is left totally unset, though random, and though causes the segfault!
(I think)

> ...
> 
> .L211:
>         .loc 1 1300 0
>         movl    cl_options_count, %ebx
>         movl    %ebx, (%esp)
>         call    xmalloc
>         movl    %eax, printed.20731
>         jmp     .L157
> 
> ...
> ------------------------------
> 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] cc1 and cc1plus --help core

[pinskia at gcc dot gnu dot org]

------- Comment #16 from pinskia at gcc dot gnu dot org  2006-01-16 03:03 -------
mov    %ebx,0x85ac8f4

We are writting to cl_options_count for some reason.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |rtl-optimization
           Keywords|                            |wrong-code
            Summary|cc1 and cc1plus --help core |[4.2 Regression] cc1 and
                   |                            |cc1plus --help core
   Target Milestone|---                         |4.2.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #17 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 03:09 -------
(In reply to comment #16)
> mov    %ebx,0x85ac8f4
> 
> We are writting to cl_options_count for some reason.

Yes, it is unnecessary, but not wrong, since if you take a closer look, it is
just

movl    cl_options_count, %ebx
...
movl    %ebx, cl_options_count

no change of %ebx in between, and I don't think it is the main issue, here.
I still think it is just the unset third argument of the memset call.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] cc1 and cc1plus --help core

[pinskia at gcc dot gnu dot org]

------- Comment #18 from pinskia at gcc dot gnu dot org  2006-01-16 03:11 -------
(In reply to comment #17)
> Yes, it is unnecessary, but not wrong, since if you take a closer look, it is
> just

Actually it is wrong as it is in read only memory.

(insn:TI 412 535 40 ../../gcc/opts.c:1301 (set (mem/u/c/i:SI (symbol_ref:SI
("cl_options_count") [flags 0x40] <var_decl 0xb7bd8160 cl_options_count>) [3
cl_options_count+0 S4 A32])
        (reg:SI 3 bx [orig:143 cl_options_count ] [143])) 34 {*movsi_1} (nil)
    (expr_list:REG_EQUIV (mem/u/c/i:SI (symbol_ref:SI ("cl_options_count")
[flags 0x40] <var_decl 0xb7bd8160 cl_options_count>) [3 cl_options_count+0 S4
A32])
        (nil)))


This is caused by reload.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #19 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 03:16 -------
(In reply to comment #18)
> (In reply to comment #17)
> > Yes, it is unnecessary, but not wrong, since if you take a closer look, it is
> > just
> 
> Actually it is wrong as it is in read only memory.

OK, then there may actually be two bugs at once. Or is my argument about the
missing third argument wrong? Am I missing something somewhere?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] cc1 and cc1plus --help core

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #20 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 03:25 -------
(In reply to comment #18)
> (In reply to comment #17)
> > Yes, it is unnecessary, but not wrong, since if you take a closer look, it is
> > just
> 
> Actually it is wrong as it is in read only memory.
> 
> (insn:TI 412 535 40 ../../gcc/opts.c:1301 (set (mem/u/c/i:SI (symbol_ref:SI
> ("cl_options_count") [flags 0x40] <var_decl 0xb7bd8160 cl_options_count>) [3
> cl_options_count+0 S4 A32])
>         (reg:SI 3 bx [orig:143 cl_options_count ] [143])) 34 {*movsi_1} (nil)
>     (expr_list:REG_EQUIV (mem/u/c/i:SI (symbol_ref:SI ("cl_options_count")
> [flags 0x40] <var_decl 0xb7bd8160 cl_options_count>) [3 cl_options_count+0 S4
> A32])
>         (nil)))

I assume this means "read-only" just as a hint for the compiler, right? Not
that it would really actually reside in a "read-only" memory. So the writing
should not cause the segfault. It is the memset that causes the segfault, no?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[pinskia at gcc dot gnu dot org]

------- Comment #21 from pinskia at gcc dot gnu dot org  2006-01-16 03:28 -------
(In reply to comment #20)
> I assume this means "read-only" just as a hint for the compiler, right? Not
> that it would really actually reside in a "read-only" memory. So the writing
> should not cause the segfault. It is the memset that causes the segfault, no?

No, it is not just a hint to compiler, the writting to read only memory is
causing the seg fault look at the instruction which is seg faulting, it is the
write.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2 Regression] cc1 and    |[4.2 Regression] opts.c is
                   |cc1plus --help core         |being miscompiled, write to
                   |                            |read only memory


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[pinskia at gcc dot gnu dot org]

------- Comment #22 from pinskia at gcc dot gnu dot org  2006-01-16 03:32 -------
Looks like PR 15248 is not really fixed on the mainline.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |15248


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #23 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 03:33 -------
(In reply to comment #20)
> (In reply to comment #18)
> > (In reply to comment #17)
> > > Yes, it is unnecessary, but not wrong, since if you take a closer look, it is
> > > just
> > 
> > Actually it is wrong as it is in read only memory.
> > 
> > (insn:TI 412 535 40 ../../gcc/opts.c:1301 (set (mem/u/c/i:SI (symbol_ref:SI
> > ("cl_options_count") [flags 0x40] <var_decl 0xb7bd8160 cl_options_count>) [3
> > cl_options_count+0 S4 A32])
> >         (reg:SI 3 bx [orig:143 cl_options_count ] [143])) 34 {*movsi_1} (nil)
> >     (expr_list:REG_EQUIV (mem/u/c/i:SI (symbol_ref:SI ("cl_options_count")
> > [flags 0x40] <var_decl 0xb7bd8160 cl_options_count>) [3 cl_options_count+0 S4
> > A32])
> >         (nil)))
> 
> I assume this means "read-only" just as a hint for the compiler, right? Not
> that it would really actually reside in a "read-only" memory. So the writing
> should not cause the segfault. It is the memset that causes the segfault, no?

Well, OK, looking at freddy's back trace:

Program received signal SIGSEGV, Segmentation fault.
0x083580bd in print_filtered_help (flag=536870912) at ../.././gcc/opts.c:1301
1301          memset (printed, 0, cl_options_count);
(gdb) bt
#0  0x083580bd in print_filtered_help (flag=536870912) at
../.././gcc/opts.c:1301
#1  0x08358f53 in decode_options (argc=2, argv=0xbf830644) at
../.././gcc/opts.c:1250
#2  0x083bf9b0 in toplev_main (argc=2, argv=0xbf830644) at
../.././gcc/toplev.c:1974
#3  0x080b8e6f in main (argc=0, argv=0x259) at ../.././gcc/main.c:35

it really looks as that writing, but I still didn't figure out where is the
third argument of the memset. Do you see it set somewhere?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #24 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 03:34 -------
(In reply to comment #22)
> Looks like PR 15248 is not really fixed on the mainline.

Yes, the commit there seems to be only from the 4_0 branch.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[pinskia at gcc dot gnu dot org]

------- Comment #25 from pinskia at gcc dot gnu dot org  2006-01-16 03:39 -------
CCing Bernd Schmidt as he is the reload expert and the fact he touched reload
code for rejecting read only memory reloads.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernds at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[pinskia at gcc dot gnu dot org]

------- Comment #26 from pinskia at gcc dot gnu dot org  2006-01-16 03:40 -------
(In reply to comment #24)
> (In reply to comment #22)
> > Looks like PR 15248 is not really fixed on the mainline.
> 
> Yes, the commit there seems to be only from the 4_0 branch.

It was also commited to the other brances too and then reverted on the mainline
and then "fixed" a different way but it was not fully fixed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[drab at kepler dot fjfi dot cvut dot cz]

------- Comment #27 from drab at kepler dot fjfi dot cvut dot cz  2006-01-16 03:42 -------
(In reply to comment #23)

...
> it really looks as that writing, but I still didn't figure out where is the
> third argument of the memset. Do you see it set somewhere?

OK, I think I see it now. The only explanation is that the memset doesn't have
register arguments. Then it IS there. Is that the case?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[pinskia at gcc dot gnu dot org]

------- Comment #28 from pinskia at gcc dot gnu dot org  2006-01-22 01:26 -------
(In reply to comment #27)
> OK, I think I see it now. The only explanation is that the memset doesn't have
> register arguments. Then it IS there. Is that the case?
Yes the memset is there, we just had not called it yet.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[bernds_cb1 at t-online dot de]

------- Comment #29 from bernds_cb1 at t-online dot de  2006-01-24 15:18 -------
Does anyone have a preprocessed source file handy?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[pinskia at gcc dot gnu dot org]

------- Comment #30 from pinskia at gcc dot gnu dot org  2006-02-09 18:03 -------
*** Bug 26200 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[pinskia at gcc dot gnu dot org]

------- Comment #31 from pinskia at gcc dot gnu dot org  2006-02-13 01:48 -------
*** Bug 26249 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dann at godzilla dot ics dot
                   |                            |uci dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[pinskia at gcc dot gnu dot org]

------- Comment #32 from pinskia at gcc dot gnu dot org  2006-02-14 12:21 -------
*** Bug 26274 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |uros at kss-loka dot si


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[bernds_cb1 at t-online dot de]

------- Comment #33 from bernds_cb1 at t-online dot de  2006-02-14 23:27 -------
Candidate patch posted in
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01100.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[bernds at gcc dot gnu dot org]

------- Comment #34 from bernds at gcc dot gnu dot org  2006-02-16 01:26 -------
Subject: Bug 25636

Author: bernds
Date: Thu Feb 16 01:26:54 2006
New Revision: 111129

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111129
Log:
        PR rtl-optimization/25636
        * local-alloc.c (update_equiv_regs): Lose a bogus rtx_equal_p test
        when deciding whether an insn is an initializing insn.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/local-alloc.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[pinskia at gcc dot gnu dot org]

------- Comment #35 from pinskia at gcc dot gnu dot org  2006-02-18 04:57 -------
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636

[Bug rtl-optimization/25636] [4.2 Regression] opts.c is being miscompiled, write to read only memory

[jakub at gcc dot gnu dot org]

------- Comment #36 from jakub at gcc dot gnu dot org  2006-07-04 13:47 -------
Subject: Bug 25636

Author: jakub
Date: Tue Jul  4 13:47:35 2006
New Revision: 115176

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115176
Log:
        PR middle-end/26991
        Backport from mainline
        2006-02-16  Bernd Schmidt  <bernd.schmidt@analog.com>

        PR rtl-optimization/25636
        * local-alloc.c (update_equiv_regs): Lose a bogus rtx_equal_p test
        when deciding whether an insn is an initializing insn.

Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/local-alloc.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25636