[Bug driver/39356] New: assembler isn't called

[Bug driver/39356] New: assembler isn't called

[r dot emrich at de dot tecosim dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4382 bytes --]

with any input

gcc -v -o hello hello.c

Es werden eingebaute Spezifikationen verwendet.
Ziel: x86_64-pc-mingw32
Konfiguriert mit: ../../../src/gcc-trunk-svn/configure
--prefix=/mingw/x86_64-pc-mingw32/mingw
--with-gmp=/home/em/install/x86_64-pc-mingw32
--with-mpfr=/home/em/install/x86_64-pc-mingw32
--with-as=/mingw/x86_64-pc-mingw32/mingw/bin/as.exe
--with-ld=/mingw/x86_64-pc-mingw32/mingw/bin/ld.exe --build=i686-pc-mingw32
--host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --enable-checking=release
--enable-languages=c
Thread-Modell: win32
gcc-Version 4.4.0 20090225 (experimental) [trunk revision 144424] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-o' 'hello.exe' '-mtune=generic'

c:/mingw/x86_64-pc-mingw32/mingw/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/cc1.exe
-quiet -v -iprefix
c:\mingw\x86_64-pc-mingw32\mingw\bin\../lib/gcc/x86_64-pc-mingw32/4.4.0/
hello.c -quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -o
C:\DOCUME~1\em\LOCALS~1\Temp\cc5VXXpW.s
doppeltes Verzeichnis »/mingw/x86_64-pc-mingw32/mingw/include« wird ignoriert
doppeltes Verzeichnis
»c:/mingw/x86_64-pc-mingw32/mingw/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/include«
wird ignoriert
doppeltes Verzeichnis
»c:/mingw/x86_64-pc-mingw32/mingw/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/include-fixed«
wird ignoriert
nicht vorhandenes Verzeichnis
»c:/mingw/x86_64-pc-mingw32/mingw/lib/gcc/../../x86_64-pc-mingw32/include« wird
ignoriert
nicht vorhandenes Verzeichnis »/mingw/include64« wird ignoriert
#include "..." - Suche beginnt hier:
#include <...> - Suche beginnt hier:

c:\mingw\x86_64-pc-mingw32\mingw\bin\../lib/gcc/x86_64-pc-mingw32/4.4.0/include

c:\mingw\x86_64-pc-mingw32\mingw\bin\../lib/gcc/x86_64-pc-mingw32/4.4.0/include-fixed
 C:/MinGW/x86_64-pc-mingw32/mingw/include
Ende der Suchliste.
GNU C (GCC) Version 4.4.0 20090225 (experimental) [trunk revision 144424]
(x86_64-pc-mingw32)
        kompiliert von GNU-C-Version 4.4.0 20090225 (experimental) [trunk
revision 144424], GMP-Version 4.2.4, MPFR-Version 2.4.0.
GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 51a3f1cecc6611139c0ed63114b596b6
COLLECT_GCC_OPTIONS='-v' '-o' 'hello.exe' '-mtune=generic'
COMPILER_PATH=c:/mingw/x86_64-pc-mingw32/mingw/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../libexec/gcc/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/bin/
LIBRARY_PATH=c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../
COLLECT_GCC_OPTIONS='-v' '-o' 'hello.exe' '-mtune=generic'

c:/mingw/x86_64-pc-mingw32/mingw/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/collect2.exe
-Bdynamic -o hello.exe
c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/crt2.o
c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/crtbegin.o
-Lc:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0
-Lc:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc
-Lc:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib
-Lc:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../..
hello.c -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt -luser32
-lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex
-lmsvcrt
c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/crtend.o
hello.c: file not recognized: File format not recognized
collect2: ld gab 1 als Ende-Status zurück


-- 
           Summary: assembler isn't called
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: r dot emrich at de dot tecosim dot com
 GCC build triplet: x86_64-pc-mingw32
  GCC host triplet: x86_64-pc-mingw32
GCC target triplet: x86_64-pc-mingw32


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

[Bug driver/39356] assembler isn't called

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-03-03 16:57 -------
Huh.  It's not even compiling.


-- 


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

[Bug driver/39356] assembler isn't called

[r dot emrich at de dot tecosim dot com]

------- Comment #2 from r dot emrich at de dot tecosim dot com  2009-03-04 09:07 -------
(In reply to comment #1)
> Huh.  It's not even compiling.
> 

You're right.

OTOH the sequence
$ gcc -v -S hello.c 
$ gcc -v -c hello.s
$ gcc -v -o hello hello.o
builds correctly.

Anyway the driver is broken for x86_64-pc-mingw32.
Perhaps somebody can point Kai Tietz to that problem, eventually he has some
glue.


-- 


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

[Bug driver/39356] assembler isn't called

[ktietz at gcc dot gnu dot org]

------- Comment #3 from ktietz at gcc dot gnu dot org  2009-03-06 15:12 -------
Well, the issues in driver seems to be related to pexecute in protoize.c. On a
first glance, I noticed that here for pid's an 'int' type is used (btw in
libiberty a 'long' is used for keeping the pids, which is for w64 incorrect,
too).
The problem is, that pid_t has to have a scalar size on w64 of 64-bits.


-- 

ktietz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ktietz at gcc dot gnu dot
                   |                            |org
         AssignedTo|unassigned at gcc dot gnu   |ktietz at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-03-06 15:12:19
               date|                            |


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

[Bug driver/39356] assembler isn't called

[ktietz at gcc dot gnu dot org]

------- Comment #4 from ktietz at gcc dot gnu dot org  2009-03-07 10:46 -------
(In reply to comment #3)
> Well, the issues in driver seems to be related to pexecute in protoize.c. On a
> first glance, I noticed that here for pid's an 'int' type is used (btw in
> libiberty a 'long' is used for keeping the pids, which is for w64 incorrect,
> too).
> The problem is, that pid_t has to have a scalar size on w64 of 64-bits.
> 

Sorry, pex_run & co aren't the reason for this issue. By further debugging I
found that for bigger functions using alloca with variable sizes wrong code is
generated for optimizations bigger then -O0.
By this reason the driver gcc.c in execute is broken. The interesting issue
about this is, when trying to make a smaller testcase out of it, code is
produced correct.


-- 


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

[Bug driver/39356] assembler isn't called

[r dot emrich at de dot tecosim dot com]

------- Comment #5 from r dot emrich at de dot tecosim dot com  2009-03-09 15:07 -------
(In reply to comment #4)
> Sorry, pex_run & co aren't the reason for this issue. By further debugging I
> found that for bigger functions using alloca with variable sizes wrong code is
> generated for optimizations bigger then -O0.
> By this reason the driver gcc.c in execute is broken. The interesting issue
> about this is, when trying to make a smaller testcase out of it, code is
> produced correct.
> 

I can confirm this. Building the compiler with CFLAGS="-O0" results in a
working driver.


-- 


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

[Bug driver/39356] assembler isn't called

[ktietz at gcc dot gnu dot org]

------- Comment #6 from ktietz at gcc dot gnu dot org  2009-03-15 20:08 -------
This bug was reasoned by duplicate existance of function __chkstk.
For targets mingw/cygwin this symbol allocates and probes stack (see
/gcc/config/i386/cygwin.asm). The VC variant export the same symbol name in
kernel32, ntdll, and ntoskernl. But the MS variant just probes the stack and
does not allocates stack space.
I temporary removed the exports from our .def files in mingw-w64 and this
solves the issue so far.
The bad side of this fix is, that libraries generated by VC can't be linked
proper, if they reference the ms __chkstk variant.


-- 


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

[Bug driver/39356] assembler isn't called

[ktietz at gcc dot gnu dot org]

------- Comment #7 from ktietz at gcc dot gnu dot org  2009-03-15 20:13 -------
The following patch solves this problem and prevents the name collision for 32
and 64 bits win32 systems.

ChangeLog

        * config/i386/i386.md (allocate_stack_worker_32): Use
        ___gnu_chkstk.
        (allocate_stack_worker_64): Likewise.
        * config/i386/cygwin.asm (__alloca): Renamed to __gnu_alloca.
        (___chkstk): Renamed to ___gnu_chkstk.

Index: gcc/gcc/config/i386/cygwin.asm
===================================================================
--- gcc.orig/gcc/config/i386/cygwin.asm
+++ gcc/gcc/config/i386/cygwin.asm
@@ -40,11 +40,11 @@
    increments is necessary to ensure that the guard pages used
    by the OS virtual memory manger are allocated in correct sequence.  */

-       .global ___chkstk
-       .global __alloca
 #ifndef _WIN64
-___chkstk:
-__alloca:
+       .global ___gnu_chkstk
+       .global ___gnu_alloca
+___gnu_chkstk:
+__gnu_alloca:
        pushl   %ecx            /* save temp */
        leal    8(%esp), %ecx   /* point past return addr */
        cmpl    $0x1000, %eax   /* > 4k ?*/
@@ -72,9 +72,11 @@ Ldone:
        pushl   %eax
        ret
 #else
+       .global ___gnu_chkstk
+       .global __gnu_alloca
 /* __alloca is a normal function call, which uses %rcx as the argument.  And
stack space
    for the argument is saved.  */
-__alloca:
+__gnu_alloca:
        movq    %rcx, %rax
        addq    $0x7, %rax
        andq    $0xfffffffffffffff8, %rax
@@ -107,7 +109,7 @@ Ldone_alloca:
 /* ___chkstk is a *special* function call, which uses %rax as the argument.
    We avoid clobbering the 4 integer argument registers, %rcx, %rdx,
    %r8 and %r9, which leaves us with %rax, %r10, and %r11 to use.  */
-___chkstk:
+___gnu_chkstk:
        addq    $0x7, %rax      /* Make sure stack is on alignment of 8.  */
        andq    $0xfffffffffffffff8, %rax
        popq    %r11            /* pop return address */
Index: gcc/gcc/config/i386/i386.md
===================================================================
--- gcc.orig/gcc/config/i386/i386.md
+++ gcc/gcc/config/i386/i386.md
@@ -20297,7 +20297,7 @@
    (set (reg:SI SP_REG) (minus:SI (reg:SI SP_REG) (match_dup 1)))
    (clobber (reg:CC FLAGS_REG))]
   "!TARGET_64BIT && TARGET_STACK_PROBE"
-  "call\t___chkstk"
+  "call\t___gnu_chkstk"
   [(set_attr "type" "multi")
    (set_attr "length" "5")])

@@ -20310,7 +20310,7 @@
    (clobber (reg:DI R11_REG))
    (clobber (reg:CC FLAGS_REG))]
   "TARGET_64BIT && TARGET_STACK_PROBE"
-  "call\t___chkstk"
+  "call\t___gnu_chkstk"
   [(set_attr "type" "multi")
    (set_attr "length" "5")])


-- 


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

[Bug driver/39356] assembler isn't called

[dannysmith at users dot sourceforge dot net]

------- Comment #8 from dannysmith at users dot sourceforge dot net  2009-03-16 02:13 -------
(In reply to comment #7)
> The following patch solves this problem and prevents the name collision for 32
> and 64 bits win32 systems.
> 
> ChangeLog
> 
>         * config/i386/i386.md (allocate_stack_worker_32): Use
>         ___gnu_chkstk.
>         (allocate_stack_worker_64): Likewise.
>         * config/i386/cygwin.asm (__alloca): Renamed to __gnu_alloca.
>         (___chkstk): Renamed to ___gnu_chkstk.
> 
No. This breaks backward compatibility.  Static libraries and objects built
with current and older versions of gcc will not be able to resolve references
to __alloca or ___chkstk.    Why not add labels with the new names as aliases
rather than replace.

Danny


-- 


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

[Bug driver/39356] assembler isn't called

[ktietz at gcc dot gnu dot org]

------- Comment #9 from ktietz at gcc dot gnu dot org  2009-03-16 09:15 -------
(In reply to comment #8)
> (In reply to comment #7)
> > The following patch solves this problem and prevents the name collision for 32
> > and 64 bits win32 systems.
> > 
> > ChangeLog
> > 
> >         * config/i386/i386.md (allocate_stack_worker_32): Use
> >         ___gnu_chkstk.
> >         (allocate_stack_worker_64): Likewise.
> >         * config/i386/cygwin.asm (__alloca): Renamed to __gnu_alloca.
> >         (___chkstk): Renamed to ___gnu_chkstk.
> > 
> No. This breaks backward compatibility.  Static libraries and objects built
> with current and older versions of gcc will not be able to resolve references
> to __alloca or ___chkstk.    Why not add labels with the new names as aliases
> rather than replace.
> 
> Danny
> 

Ok, for 32-bits this makes sense to keep the old symbol names. Beside there is
still a chance that a user uses the manually the chkstk.o file, which can lead
to undefined behaviour (at least if the user code references __chkstk).
For 64-bit I prefer to avoid those old names and simply rename it.
Is this ok for you? I'll file then a patch for it?

Kai


-- 


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

[Bug driver/39356] assembler isn't called

[ktietz at gcc dot gnu dot org]

------- Comment #10 from ktietz at gcc dot gnu dot org  2009-03-19 14:33 -------
(In reply to comment #9)

Patch sent. See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html


-- 


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

[Bug driver/39356] assembler isn't called

[nightstrike at gmail dot com]

------- Comment #11 from nightstrike at gmail dot com  2009-03-20 05:28 -------
I can confirm that our 4.3 release worked, and that this is a 4.4 regression.


-- 


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

[Bug driver/39356] assembler isn't called

[xenofears at gmail dot com]

------- Comment #12 from xenofears at gmail dot com  2009-06-22 01:11 -------
(In reply to comment #10)
> (In reply to comment #9)
> Patch sent. See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00914.html

(I am new as an official team member of Mingw-w64, and am making a project of
my own based on it. You will see it by tomorrow morning at
http://www.cadforte.com for now, which I own and run in my own network.
Greetings everyone.)

I can confirm this works, with optimization set to -O0. Windows x64 native
still fails in stage 2 with -O2, as is default for the bootstrap. I will report
this as a separate bug. In addition, -DCLOOG_PPL_BACKEND fails in stage 1.

I have been trying to build native x64 gcc for weeks, and you can expect other
reports from me.


-- 


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

[Bug driver/39356] assembler isn't called

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2009-06-22 01:42 -------
*** Bug 40513 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xenofears at gmail dot com


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

[Bug driver/39356] assembler isn't called

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2009-06-22 01:42 -------
*** Bug 40514 has been marked as a duplicate of this bug. ***


-- 


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

[Bug driver/39356] assembler isn't called

[rainer at emrich-ebersheim dot de]

------- Comment #15 from rainer at emrich-ebersheim dot de  2009-07-22 12:24 -------
Is there a chance that we get this fixed soon?

Rainer


-- 


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

[Bug driver/39356] assembler isn't called

[ktietz at gcc dot gnu dot org]

------- Comment #16 from ktietz at gcc dot gnu dot org  2009-07-22 16:06 -------
(In reply to comment #15)
> Is there a chance that we get this fixed soon?
> 
> Rainer
> 

Well, I would like to fix this. Better now then later. But I couldn't find the
real reason for this issue. The patch above solved the problem on 4.4.0 branch
some time ago, but now it seems to be a different issue. But AFAICT is is
related to chkstk/alloca here.

Cheers,
Kai


-- 


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

[Bug driver/39356] assembler isn't called

[ktietz at gcc dot gnu dot org]

------- Comment #17 from ktietz at gcc dot gnu dot org  2009-08-30 08:35 -------
(In reply to comment #16)
> (In reply to comment #15)
> > Is there a chance that we get this fixed soon?
> > 
> > Rainer
> > 
> 
> Well, I would like to fix this. Better now then later. But I couldn't find the
> real reason for this issue. The patch above solved the problem on 4.4.0 branch
> some time ago, but now it seems to be a different issue. But AFAICT is is
> related to chkstk/alloca here.
> 
> Cheers,
> Kai
> 

Could you please test if issue still exist for trunk and current 4.4 branch. It
could be a duplicate of PR/41184.

Cheers,
Kai


-- 


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

[Bug driver/39356] assembler isn't called

[rainer at emrich-ebersheim dot de]

------- Comment #18 from rainer at emrich-ebersheim dot de  2009-08-31 08:11 -------
Subject: Re:  assembler isn't called

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ktietz at gcc dot gnu dot org schrieb:
> ------- Comment #17 from ktietz at gcc dot gnu dot org  2009-08-30 08:35 -------
> (In reply to comment #16)
>> (In reply to comment #15)
>>> Is there a chance that we get this fixed soon?
>>>
>>> Rainer
>>>
>> Well, I would like to fix this. Better now then later. But I couldn't find the
>> real reason for this issue. The patch above solved the problem on 4.4.0 branch
>> some time ago, but now it seems to be a different issue. But AFAICT is is
>> related to chkstk/alloca here.
>>
>> Cheers,
>> Kai
>>
> 
> Could you please test if issue still exist for trunk and current 4.4 branch. It
> could be a duplicate of PR/41184.
> 
> Cheers,
> Kai
> 
> 
I will try, but probably not before Wednesday.

Cheers,
Rainer

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkqbhZMACgkQoUhjsh59BL5I8gCgiofn0d3yJ1v7DnkIH9hGr3y8
DzAAn1aDUGlbuS64F44c/p7woSY5J5oI
=f36P
-----END PGP SIGNATURE-----


-- 


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

[Bug driver/39356] assembler isn't called

[ktietz at gcc dot gnu dot org]

------- Comment #19 from ktietz at gcc dot gnu dot org  2009-09-01 16:16 -------
I verified it by myself and it is a duplicate of 41184

*** This bug has been marked as a duplicate of 41184 ***


-- 

ktietz at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |DUPLICATE


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