[Bug bootstrap/41473] New: [4.5 Regression] dsymutil "Assertion failed ..." since revision 151907

[Bug bootstrap/41473] New: [4.5 Regression] dsymutil "Assertion failed ..." since revision 151907

[dominiq at lps dot ens dot fr]

I open this PR to keep a record of the minor issue found in pr41405. For some
libraries dsymutil gives for instance on i686-apple-darwin9 r152145:

19259 - libtool: link: dsymutil .libs/libstdc++.6.dylib || :
19260 : Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
19261 + ../libtool: line 7996: 53016 Abort trap              dsymutil
.libs/libstdc++.6.dylib
22118 - libtool: link: dsymutil .libs/libstdc++.6.dylib || :
22119 : Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
22120 + ../libtool: line 7996: 56489 Abort trap              dsymutil
.libs/libstdc++.6.dylib
36201 - libtool: link: dsymutil .libs/libgcj.11.dylib || :
36202 : Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
36203 + warning: {0x00096f4c} TAG_variable:  AT_location( 0x000760de ) didn't
have valid function low pc, the location list will be incorrect.

while on powerpc-apple-darwin9 r152135 I get:

17913 - libtool: link: dsymutil .libs/libstdc++.6.dylib || :
17914 : Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
17915 + ../libtool: line 7996:  2024 Abort trap              dsymutil
.libs/libstdc++.6.dylib
20787 - libtool: link: dsymutil .libs/libstdc++.6.dylib || :
20788 : Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
20789 + ../libtool: line 7996:  5504 Abort trap              dsymutil
.libs/libstdc++.6.dylib
24341 - libtool: link: dsymutil .libs/libgfortran.3.dylib || :
24342 : Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
24343 + ./libtool: line 7996: 43560 Abort trap              dsymutil
.libs/libgfortran.3.dylib
34863 - libtool: link: dsymutil .libs/libgcj.11.dylib || :
34864 : Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
34865 + ./libtool: line 7996: 56377 Abort trap              dsymutil
.libs/libgcj.11.dylib
39262 - libtool: link: dsymutil .libs/libgcj.11.dylib || :
39263 : Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
39264 + ./libtool: line 7996:  4174 Abort trap              dsymutil
.libs/libgcj.11.dylib

It is probably not surprising that these libraries don't have the *.dSYM
directory

[karma] gcc/darwin_buildw% lf
powerpc-apple-darwin9/libgfortran/.libs/libgfortran.3.dylib*
powerpc-apple-darwin9/libgfortran/.libs/libgfortran.3.dylib*
[karma] gcc/darwin_buildw% lf
powerpc-apple-darwin9/ppc64/libgfortran/.libs/libgfortran.3.dylib*
powerpc-apple-darwin9/ppc64/libgfortran/.libs/libgfortran.3.dylib*

powerpc-apple-darwin9/ppc64/libgfortran/.libs/libgfortran.3.dylib.dSYM:
Contents/


-- 
           Summary: [4.5 Regression] dsymutil "Assertion failed ..." since
                    revision 151907
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: *-apple-darwin*
  GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*


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

[Bug bootstrap/41473] [4.5 Regression] dsymutil "Assertion failed ..." since revision 151907

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2009-09-26 11:19 -------
How's that a GCC bug?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


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

[Bug bootstrap/41473] [4.5 Regression] dsymutil "Assertion failed ..." since revision 151907

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2009-09-26 12:10 -------
> How's that a GCC bug?

Can you PROVE it is not? If you have a PROOF, could you be kind enough to post
it so we can fill a bug report upstream. Meanwhile the WAITING status is fine.


-- 

dominiq at lps dot ens dot fr changed:

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


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

[Bug bootstrap/41473] [4.5 Regression] dsymutil "Assertion failed ..." since revision 151907

[rguenther at suse dot de]

------- Comment #3 from rguenther at suse dot de  2009-09-26 12:13 -------
Subject: Re:  [4.5 Regression] dsymutil "Assertion failed
 ..." since revision 151907

On Sat, 26 Sep 2009, dominiq at lps dot ens dot fr wrote:

> ------- Comment #2 from dominiq at lps dot ens dot fr  2009-09-26 12:10 -------
> > How's that a GCC bug?
> 
> Can you PROVE it is not? If you have a PROOF, could you be kind enough to post
> it so we can fill a bug report upstream. Meanwhile the WAITING status is fine.

I can't PROVE it.  But I think it's not the obligation of GCC developers
to prove that a bug is not a bug in GCC.  It is up to the reporter to
make reasonable arguments that a bug is a GCC bug, for example by
providing a testcase that makes the bug show up with only GCC tools,
or by showing GCC output and comparing it to whatever specs exist
for the output format and show that GCC doesn't conform.

So, file the bug report upstream please.  By your reasoning they'd have
to PROVE that it isn't their bug.

Richard.


-- 


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

[Bug bootstrap/41473] [4.5 Regression] dsymutil "Assertion failed ..." since revision 151907

[dominiq at lps dot ens dot fr]

------- Comment #4 from dominiq at lps dot ens dot fr  2009-09-27 11:44 -------
Running valgrind I got:

--77271-- /Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgfortran.3.dylib:
--77271-- dSYM directory has wrong UUID; consider using --auto-run-dsymutil=yes
--77271-- /Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgcc_s.1.dylib:
--77271-- dSYM directory has wrong UUID; consider using --auto-run-dsymutil=yes

So I rerun valgrind with --auto-run-dsymutil=yes and got:

--77275-- run: /usr/bin/dsymutil
/Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgfortran.3.dylib
--77275-- run: /usr/bin/dsymutil
/Volumes/MacBook/opt/gcc/gcc4.5w/lib/libgcc_s.1.dylib

without error or warning.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2009-09-27 12:27 -------
Target issue.  r151907 is not the revision that caused this.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|bootstrap                   |target
           Keywords|                            |build
            Summary|[4.5 Regression] dsymutil   |[4.5 Regression] dsymutil
                   |"Assertion failed ..." since|"Assertion failed ..."
                   |revision 151907             |
   Target Milestone|---                         |4.5.0


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-09-27 12:32 -------
Simple googling leads me to

http://wiki.dwarfstd.org/index.php?title=Apple's_"Lazy"_DWARF_Scheme

which in turn makes me think a recent libtool update may be the
real "cause" of this, making this a libtool bug, not a gcc bug.

> 19259 - libtool: link: dsymutil .libs/libstdc++.6.dylib || :
> 19260 : Assertion failed: (orig_str), function FixReferences, file
> /SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
> 3641.
> 19261 + ../libtool: line 7996: 53016 Abort trap              dsymutil
> .libs/libstdc++.6.dylib

look how libtool invokes dsymutil here which in turn might get confused
by the dwarf from gcc 4.5 and leaves behind a state that in turn causes
"dSYM directory has wrong UUID".  So in the end this is very likely still
a dsymutil bug - no user program should run into assertions anyway.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[developer at sandoe-acoustics dot co dot uk]

------- Comment #7 from developer at sandoe-acoustics dot co dot uk  2009-09-28 01:18 -------
(In reply to comment #6)

this issue was introduced by the changes in 151901.
(I can obtain a successful bootstrap by reverting the changes of 151815, the
dsymutil fail is then present, not present at 151900 with the changes of 151815
reverted).

thanks for the pointer to possible libtool influence, however, the
libtool-version listed in (e.g.) libgfortran claims not to have changed between
151000 and152000.

>  So in the end this is very likely still
> a dsymutil bug - no user program should run into assertions anyway.

agreed;  however, at the moment I can't repeat this outside the GCC build
process.

running the command line (listed as failing in the log) manually on the
freshly-built tree does not fail.
"dwarfdump -av *.o" doesn't reveal any failures.

if I build a lib by hand with the objects present and then run dsymutil on it -
it doesn't fail.

I'm also finding it difficult to check the dwarf-4 stuff since none of google,
wiki or the gcc website are pointing to a  DWARF4 spec to read.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #8 from dominiq at lps dot ens dot fr  2009-11-13 13:22 -------
Between revisions 154095 and 154111, fifteen new failures appeared on the test
performed by regress (see
http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01028.html):

...
FAIL: gcc.dg/torture/complex-sign-add.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/complex-sign-mixed-add.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/complex-sign-mixed-div.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/complex-sign-mul-minus-one.c  -O3 -g  (test for excess
errors)
FAIL: gcc.dg/torture/complex-sign-mul-one.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/complex-sign-mul.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/torture/complex-sign-sub.c  -O3 -g  (test for excess errors)
...
FAIL: gcc.dg/vmx/3b-10.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/bug-3.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/gcc-bug-e.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/gcc-bug-i.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/sn7153.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/varargs-1.c  -O3 -g  (test for excess errors)
FAIL: gcc.dg/vmx/x-04.c  -O3 -g  (test for excess errors)
FAIL: gcc.misc-tests/gcov-2.c (test for excess errors)
...

A quick look at
http://gcc.gnu.org/regtest/HEAD/native-logsum/gcc/testsuite/gcc/gcc.log.gzip
shows that these failures come from:

Executing on host: /Users/regress/tbox/native/build/gcc/xgcc
-B/Users/regress/tbox/native/build/gcc/
/Users/regress/tbox/svn-gcc/gcc/testsuite/gcc.misc-tests/gcov-2.c  
-fprofile-arcs -ftest-coverage -g      -o ./gcov-2.exe    (timeout = 300)
Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-49/source/DWARFdSYM.cpp, line
3157.
xgcc: Internal error: Abort trap (program dsymutil)

Note that I don't see these failure on my build for powerpc-apple-darwin9
[trunk revision 154131].


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #9 from dominiq at lps dot ens dot fr  2009-11-16 10:34 -------
The failures reported in comment #8 have disappeared between revisions 154188
and 154190 (compare http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01435.html
and http://gcc.gnu.org/ml/gcc-testresults/2009-11/msg01388.html), likely fixed
by revision 154189:

        * gcc.dg/lto/lto.exp: For non-lto, bail out before calling
        init functions.


Is it right to conclude that the failures were due to revision 154104?

2009-11-11  H.J. Lu  <hongjiu.lu@intel.com>

        PR testsuite/42001
        * gcc.dg/lto/lto.exp: Pass no-mathlib to lto_init.  Call
        lto_finish at the end.

        * lib/lto.exp (lto_init): Set mathlib to " " for no-mathlib.
        (lto_finish): New. Restore mathlib.

If yes, understanding the origin of the failures triggered by revision 154104
may help to produce a reduced test case for this PR.


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hjl dot tools at gmail dot
                   |                            |com, hp at axis dot com


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[hp at gcc dot gnu dot org]

------- Comment #10 from hp at gcc dot gnu dot org  2009-11-16 10:57 -------
(In reply to comment #9)
> The failures reported in comment #8 have disappeared between revisions 154188
> and 154190 
> Is it right to conclude that the failures were due to revision 154104?

*shrug* your call.
At a glance it appears they're "due to" a bug in dsymutil, apparently "trigged
by" dropping -lm as per 154104.  Have a look at
<http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00732.html>.


-- 

hp at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|hp at axis dot com          |hp at gcc dot gnu dot org


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #11 from dominiq at lps dot ens dot fr  2009-11-16 14:29 -------
The following code triggers the problem on i686-apple-darwin9 at revision
154075 (+ patches from fortran-dev):

[ibook-dhum] f90/bug% cat complex-sign-add_red_1.c
extern void exit (int);

void
check_add_float (void)
{
  _Complex float a1;
  volatile _Complex float a2, b2, c2; 
  a1 = (+ 1 == 1 ? + 1 == 1 ? 0.0f + 0.0if : 0.0f - 0.0if : + 1 == 1 ? -(0.0f -
0.0if) : -(0.0f + 0.0if));
  a2 = (+ 1 == 1 ? + 1 == 1 ? 0.0f + 0.0if : 0.0f - 0.0if : + 1 == 1 ? -(0.0f -
0.0if) : -(0.0f + 0.0if)); 
  b2 = (+ 1 == 1 ? + 1 == 1 ? 0.0f + 0.0if : 0.0f - 0.0if : + 1 == 1 ? -(0.0f -
0.0if) : -(0.0f + 0.0if)); 
  c2 = a2 + b2; 
}

int
main (void)
{
  check_add_float ();
  exit (0);
}
[ibook-dhum] f90/bug% gcc45 complex-sign-add_red_1.c -O1 -g -c 
[ibook-dhum] f90/bug% gcc45 complex-sign-add_red_1.o -O1 -g 
[ibook-dhum] f90/bug% dsymutil a.out
Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
Abort

The reduced case does not trigger the error on powerpc-apple-darwin9 while the
full test does.

QUESTIONS: what does gcc 4.5 put in the a.out files that triggers (or not) the
failure?
How am I supposed to find it?

Note that 'gcc45 complex-sign-add_red_1.c -O1 -g' triggers the same error, but
in both cases the executable is produced and can be run (I did not tried to
debug it). Also the dsymutil bug is not triggered at -O0. Finally 'gcc45
complex-sign-add_red_1.c -O1 -g -lm' does not gives any error due to the fact
that dsymutil is not called. The -v option gives respectively:

...
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-O1' '-g' '-v'
'-mtune=generic'
 dsymutil a.out
Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
gcc45: Internal error: Abort trap (program dsymutil)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

and

...
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.8' '-O1' '-g' '-v'
'-mtune=generic'

Is this the intended behavior?


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #12 from howarth at nitro dot med dot uc dot edu  2009-11-16 15:13 -------
Dominique,
    Can code in comment 11 be converted into a test case that can be run
through dsymutil without requiring FSF gcc to be installed? If so, please open
a radar report with that information.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #13 from dominiq at lps dot ens dot fr  2009-11-16 15:37 -------
(In reply to comment #12)
>     Can code in comment 11 be converted into a test case that can be run
> through dsymutil without requiring FSF gcc to be installed? If so, please open
> a radar report with that information.

Jack,
I am not sure to understand what you ask for. My knowledge (rather my
ignorance!-) of C makes me unable to say if there is anything non standard in
the code in comment 11. Let me repeat that the failures to use dsymutil on the
executable file is specific to gcc 4.5 and cannot repeated with the gcc shipped
by Apple nor with any gcc version I have pre-VTA merge.

My uneducated guess is that post-VTA merge gcc sometimes puts some stuff in the
executable files that trigger the assertion in dsymutil. In my opinion only
those knowing what they are doing with the dwarf information can tell us where
to look to go further.

Note that I have forgotten to mention that further reducing the test makes the
dsymutil failure to disappear (I did not tried to reduced the different
switches).


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #14 from dominiq at lps dot ens dot fr  2009-11-16 16:25 -------
I don't know if this answer the question in comment 12. I have done the
following experiment:

[ibook-dhum] f90/bug% rm -rf a.out*
[ibook-dhum] f90/bug% rm complex-sign-add_red_1.*
remove complex-sign-add_red_1.c? n
remove complex-sign-add_red_1.o? y
remove complex-sign-add_red_1.s? y
[ibook-dhum] f90/bug% gcc45 complex-sign-add_red_1.c -O1 -g -S
[ibook-dhum] f90/bug% as complex-sign-add_red_1.s -o complex-sign-add_red_1.o
[ibook-dhum] f90/bug% gcc complex-sign-add_red_1.o
[ibook-dhum] f90/bug% a.out
[ibook-dhum] f90/bug% dsymutil a.out
Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
Abort
[ibook-dhum] f90/bug% rm -rf a.out*
[ibook-dhum] f90/bug% rm complex-sign-add_red_1.*
remove complex-sign-add_red_1.c? n
remove complex-sign-add_red_1.o? y
remove complex-sign-add_red_1.s? y
[ibook-dhum] f90/bug% gcc45 complex-sign-add_red_1.c -O0 -g -S
[ibook-dhum] f90/bug% as complex-sign-add_red_1.s -o complex-sign-add_red_1.o
[ibook-dhum] f90/bug% gcc complex-sign-add_red_1.o
[ibook-dhum] f90/bug% a.out
[ibook-dhum] f90/bug% dsymutil a.out
[ibook-dhum] f90/bug% gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)
[ibook-dhum] f90/bug% as -v
Apple Inc version cctools-698.1~1, GNU assembler version 1.38
^CInterrupted by signal 2

[ibook-dhum] f90/bug% gcc45 -v
Using built-in specs.
COLLECT_GCC=gcc45
COLLECT_LTO_WRAPPER=/Volumes/MacBook/opt/gcc/gcc4.5w/bin/../libexec/gcc/i686-apple-darwin9/4.5.0/lto-wrapper
Target: i686-apple-darwin9
Configured with: ../gcc-4.5-work/configure --prefix=/opt/gcc/gcc4.5w
--mandir=/opt/gcc/gcc4.5w/share/man --infodir=/opt/gcc/gcc4.5w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --with-cloog=/sw
--with-ppl=/sw --with-mpc=/opt/mpc/build
Thread model: posix
gcc version 4.5.0 20091110 (experimental) [trunk revision 154075p3] (GCC) 

So the problem seems contained in the assembly code. I had a look at the
difference between the assembly generated with -O0 and -O1, but did not see
anything obvious (I'll attach the files later).

BTW is the test in comment 11 giving the same result on darwin10?


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #15 from howarth at nitro dot med dot uc dot edu  2009-11-16 16:27 -------
I meant if we can create a test case from an assembly file generated from FSF
gcc which can be used to trigger the problem in dsymutil in absence of FSF gcc
itself.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #16 from dominiq at lps dot ens dot fr  2009-11-16 16:31 -------
> I meant if we can create a test case from an assembly file generated from FSF
> gcc which can be used to trigger the problem in dsymutil in absence of FSF gcc
> itself.

Are the results in comment 14 answering your question? Can you reproduce it on
darwin10?


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #17 from dominiq at lps dot ens dot fr  2009-11-16 16:38 -------
Note that the dsymutil failure for the test in comment 11 disappears in 64 bit
mode.
The original code in the test suite gives:
[ibook-dhum] f90/bug% gcc45
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/torture/complex-sign-add.c -O3 -g -m64
warning: {0x00000124} TAG_variable:  AT_location( 0x0000021c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000132} TAG_variable:  AT_location( 0x00000250 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000140} TAG_variable:  AT_location( 0x00000284 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0000018b} TAG_variable:  AT_location( 0x000002b8 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000199} TAG_variable:  AT_location( 0x000002ec ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000001a7} TAG_variable:  AT_location( 0x00000320 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000001f2} TAG_variable:  AT_location( 0x00000354 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000200} TAG_variable:  AT_location( 0x00000388 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0000020e} TAG_variable:  AT_location( 0x000003bc ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000259} TAG_variable:  AT_location( 0x000003f0 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000267} TAG_variable:  AT_location( 0x00000424 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000275} TAG_variable:  AT_location( 0x00000458 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000002c0} TAG_variable:  AT_location( 0x0000048c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000002ce} TAG_variable:  AT_location( 0x000004c0 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000002dc} TAG_variable:  AT_location( 0x000004f4 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000327} TAG_variable:  AT_location( 0x00000528 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000335} TAG_variable:  AT_location( 0x0000055c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000343} TAG_variable:  AT_location( 0x00000590 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0000038e} TAG_variable:  AT_location( 0x000005c4 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0000039c} TAG_variable:  AT_location( 0x000005f8 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000003aa} TAG_variable:  AT_location( 0x0000062c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000003f5} TAG_variable:  AT_location( 0x00000660 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000403} TAG_variable:  AT_location( 0x00000694 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000411} TAG_variable:  AT_location( 0x000006c8 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0000045c} TAG_variable:  AT_location( 0x000006fc ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0000046a} TAG_variable:  AT_location( 0x00000730 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000478} TAG_variable:  AT_location( 0x00000764 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000004c3} TAG_variable:  AT_location( 0x00000798 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000004d1} TAG_variable:  AT_location( 0x000007cc ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000004df} TAG_variable:  AT_location( 0x00000800 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0000052a} TAG_variable:  AT_location( 0x00000834 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000538} TAG_variable:  AT_location( 0x00000868 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000546} TAG_variable:  AT_location( 0x0000089c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000591} TAG_variable:  AT_location( 0x000008d0 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0000059f} TAG_variable:  AT_location( 0x00000904 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000005ad} TAG_variable:  AT_location( 0x00000938 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x000005f8} TAG_variable:  AT_location( 0x0000096c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000606} TAG_variable:  AT_location( 0x000009a0 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000614} TAG_variable:  AT_location( 0x000009d4 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x0000065b} TAG_variable:  AT_location( 0x00000a08 ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000669} TAG_variable:  AT_location( 0x00000a3c ) didn't have
valid function low pc, the location list will be incorrect.
warning: {0x00000677} TAG_variable:  AT_location( 0x00000a70 ) didn't have
valid function low pc, the location list will be incorrect.
gcc45: Internal error: Segmentation fault (program dsymutil)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #18 from dominiq at lps dot ens dot fr  2009-11-16 19:01 -------
Created an attachment (id=19023)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19023&action=view)
assembly code giving an executable accepted by dsymutil

[ibook-dhum] f90/bug% rm -rf a.out*
[ibook-dhum] f90/bug% as complex-sign-add_red_1_O0.s -o
complex-sign-add_red_1_O0.o
[ibook-dhum] f90/bug% gcc complex-sign-add_red_1_O0.o
[ibook-dhum] f90/bug% dsymutil a.out
[ibook-dhum] f90/bug% 


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #19 from dominiq at lps dot ens dot fr  2009-11-16 19:03 -------
Created an attachment (id=19024)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19024&action=view)
assembly code giving an executable that fails dsymutil

[ibook-dhum] f90/bug% rm -rf a.out*
[ibook-dhum] f90/bug% as complex-sign-add_red_1_O1.s -o
complex-sign-add_red_1_O1.o
[ibook-dhum] f90/bug% gcc complex-sign-add_red_1_O1.o
[ibook-dhum] f90/bug% dsymutil a.out
Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
Abort


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #20 from dominiq at lps dot ens dot fr  2009-11-16 19:37 -------
I have filled a bug report to Apple under #7397601.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #21 from howarth at nitro dot med dot uc dot edu  2009-11-19 02:25 -------
Created an attachment (id=19040)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19040&action=view)
assembly diffs from 20090908 vs 20091118 compiler for testcase


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #22 from howarth at nitro dot med dot uc dot edu  2009-11-19 02:27 -------
In case this helps, I have attached the assembly diffs from...

gcc-4 -O1 -m32 -g --save-temps complex-sign-add_red_1.c

for the 20090908 compiler (before the VTA merge) and for the 20091118 compiler.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #23 from dominiq at lps dot ens dot fr  2009-11-19 10:56 -------
Further reduced test case:

void
check_add_float (void)
{
  _Complex float a1, a2, b2, c2; 
  a1 = 0.0f;
  a2 = a1;
  b2 = a1; 
  c2 = a2 + b2;
}

int
main (void)
{
  check_add_float ();
}

[ibook-dhum] f90/bug% gcc45 complex-sign-add_red_2.c -O1 -g
-fno-guess-branch-probability
[ibook-dhum] f90/bug% gcc45 complex-sign-add_red_2.c -O1 -g
Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
...


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu dot
                   |                            |org, jakub at redhat dot com


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #24 from dominiq at lps dot ens dot fr  2009-11-19 10:58 -------
Created an attachment (id=19045)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19045&action=view)
assembly generated with gcc45 complex-sign-add_red_2.c -O1 -g
-fno-guess-branch-probability -S

ibook-dhum] f90/bug% rm -rf a.out*
[ibook-dhum] f90/bug% as complex-sign-add_red_2_nop.s -o
complex-sign-add_red_2_nop.o
[ibook-dhum] f90/bug% gcc complex-sign-add_red_2_nop.o
[ibook-dhum] f90/bug% dsymutil a.out
[ibook-dhum] f90/bug%


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #25 from dominiq at lps dot ens dot fr  2009-11-19 10:59 -------
Created an attachment (id=19046)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19046&action=view)
assembly generated by gcc45 complex-sign-add_red_2.c -O1 -g -S

[ibook-dhum] f90/bug% as complex-sign-add_red_2_yes.s -o
complex-sign-add_red_2_yes.o
[ibook-dhum] f90/bug% gcc complex-sign-add_red_2_yes.o
[ibook-dhum] f90/bug% dsymutil a.out
Assertion failed: (orig_str), function FixReferences, file
/SourceCache/dwarf_utilities/dwarf_utilities-70/source/DWARFdSYM.cpp, line
3641.
Abort


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #26 from dominiq at lps dot ens dot fr  2009-11-19 11:00 -------
Created an attachment (id=19047)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19047&action=view)
diff between complex-sign-add_red_2_nop.s and complex-sign-add_red_2_yes.s


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #27 from howarth at nitro dot med dot uc dot edu  2009-11-19 23:27 -------
We have an update on radar 7397601 from Nick Kledzik...

   7397601 is a bug in dsymutils.  It was not handling the case when the
   dwarf debug info contained an AT_location with form DW_FORM_block1 with
   zero length.  It may also be possible to have the compiler not emit that as
   a work around.

Could we get a proposed patch to have the compiler not emit this offending
code on darwin (at least so that we can verify that this is the only source of
the dsymutils aborts after the VAR merge)?


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #28 from howarth at nitro dot med dot uc dot edu  2009-11-20 00:13 -------
Why do we have....

    case dw_val_class_const_double:
      switch (HOST_BITS_PER_WIDE_INT)
        {
        case 8:
          return DW_FORM_data2;
        case 16:
          return DW_FORM_data4;
        case 32:
          return DW_FORM_data8;
        case 64:
        default:
          return DW_FORM_block1;
        }

in gcc/dwarf2out.c? Almost all of the other case statements in the subroutine
value_format() have

        default:
          gcc_unreachable ();

for the default case.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #29 from howarth at nitro dot med dot uc dot edu  2009-11-20 18:59 -------
I have some additional comments from the dsymutils maintainer...

>>> 7397601 is a bug in dsymutils.  It was not handling the case when the
>>> dwarf debug info contained an AT_location with form DW_FORM_block1 with
>>> zero length.  It may also be possible to have the compiler not emit that
>>> as a work around.

Clarification: The fix was made for any block form (DW_FORM_block1,
DW_FORM_block2, DW_FORM_block4, DW_FORM_block) variant that had zero length.

>>   One other question. Does dwarf debug info on an AT_location with form
>> DW_FORM_block1 that has zero length have any real meaning or is
>> that likely just accidental noise on the dwarf debug output?

It is probably accidental noise, or a bug. The variable should be checked to
make sure it really doesn't have a location, and if it doesn't just don't emit
the DW_AT_location attribute. If it does have a valid location, then a lenght
of zero is probably a bug.

>> If zero length dwarf debug info, is either invalid or effectively a noop,
>> we may just be suffering from the fact binutils is immune to such flaws in
>> the dwarf output. Then, darwin might actually be useful in helping identify
>> bogus dwarf info being emitted. Thanks in advance for any clarifications.

I have modified dwarfdump to properly dump the information and I did check the
DWARF spec, and it seems that it is ok to have  DW_FORM_blockXXX forms with
zero length, so it isn't invalid DWARF.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #30 from howarth at nitro dot med dot uc dot edu  2009-11-23 14:22 -------
Perhaps something like...

Index: dwarf2out.c
===================================================================
--- dwarf2out.c (revision 154443)
+++ dwarf2out.c (working copy)
@@ -10447,8 +10447,11 @@

          /* Output the block length for this list of location operations.  */
          dw2_asm_output_data (constant_size (size), size, "%s", name);
-
-         output_loc_sequence (AT_loc (a));
+          
+          if (dwarf_strict && (size == 0))
+                break;
+          else
+               output_loc_sequence (AT_loc (a));
          break;

        case dw_val_class_const:

could fix this on darwin (untested) since we are the
only target defaulting to dwarf_strict.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[rguenther at suse dot de]

------- Comment #31 from rguenther at suse dot de  2009-11-23 14:26 -------
Subject: Re:  [4.5 Regression] dsymutil "Assertion failed
 ..."

On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote:

> ------- Comment #30 from howarth at nitro dot med dot uc dot edu  2009-11-23 14:22 -------
> Perhaps something like...
> 
> Index: dwarf2out.c
> ===================================================================
> --- dwarf2out.c (revision 154443)
> +++ dwarf2out.c (working copy)
> @@ -10447,8 +10447,11 @@
> 
>           /* Output the block length for this list of location operations.  */
>           dw2_asm_output_data (constant_size (size), size, "%s", name);
> -
> -         output_loc_sequence (AT_loc (a));
> +          
> +          if (dwarf_strict && (size == 0))
> +                break;
> +          else
> +               output_loc_sequence (AT_loc (a));
>           break;
> 
>         case dw_val_class_const:
> 
> could fix this on darwin (untested) since we are the
> only target defaulting to dwarf_strict.

Well, I don't think outputting zero-length location sequences makes
sense at all.

Richard.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #32 from howarth at nitro dot med dot uc dot edu  2009-11-23 14:38 -------
I got this response over on the gdb mailing list regarding 
the validity of emitting dwarf debug info containing an 
AT_location with any block form having a zero length...

http://sourceware.org/ml/gdb/2009-11/msg00168.html


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #33 from howarth at nitro dot med dot uc dot edu  2009-11-23 14:41 -------
I should reiterate the dsymutil's maintainers comments on this issue...

   The variable should be checked to make sure it really doesn't have a
location, 
   and if it doesn't just don't emit the DW_AT_location attribute. If it does
have a 
   valid location, then a lenght of zero is probably a bug.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[rguenth at gcc dot gnu dot org]

------- Comment #34 from rguenth at gcc dot gnu dot org  2009-11-23 14:53 -------
I suppose empty DW_AT_location lists may now denote places where the value
dies and is no longer available.  We now properly track this with VTA.

Alex?


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #35 from howarth at nitro dot med dot uc dot edu  2009-11-23 15:03 -------
If it is in fact valid dwarf, the question remains of what to do about the
breakage that this causes with dsymutil on darwin. Inhibiting the emission of
this in dwarf-strict might be a reasonable compromise since only darwin is
defaulting that on.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[rguenther at suse dot de]

------- Comment #36 from rguenther at suse dot de  2009-11-23 15:07 -------
Subject: Re:  [4.5 Regression] dsymutil "Assertion failed
 ..."

On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote:

> ------- Comment #35 from howarth at nitro dot med dot uc dot edu  2009-11-23 15:03 -------
> If it is in fact valid dwarf, the question remains of what to do about the
> breakage that this causes with dsymutil on darwin. Inhibiting the emission of
> this in dwarf-strict might be a reasonable compromise since only darwin is
> defaulting that on.

If it's valid dwarf then it is also dwarf-strict.  Please get apple
fix its tools and issue a maintainance update.  (I'm inclined to close
this bug as invalid)

Richard.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #37 from howarth at nitro dot med dot uc dot edu  2009-11-23 15:26 -------
(In reply to comment #36)
> If it's valid dwarf then it is also dwarf-strict.  Please get apple
> fix its tools and issue a maintainance update.  (I'm inclined to close
> this bug as invalid)
> 
> Richard.
> 

Apple will be fixing this for Xcode 3.2.x, but realistically it extremely
unlikely
that the fix will be backported to Xcode 3.1.x or early so you are basically
cutting off all releases earlier than Snow Leopard from generating
complete debug code in gcc trunk. Currently we can't generate dSYM's for...

 libgcj.dylib
 libgcjgc.1.dylib
 libgfortran.3.dylib
 libgomp.1.dylib
 libobjc-gnu.2.dylib
libssp.0.dylib
 libstdc++.6.dylib

because of this issue. Our only other choice left will be to carry around
non-standard patches to avoid
this problem in distributed FSF gcc binaries for darwin.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[rguenther at suse dot de]

------- Comment #38 from rguenther at suse dot de  2009-11-23 15:28 -------
Subject: Re:  [4.5 Regression] dsymutil "Assertion failed
 ..."

On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote:

> ------- Comment #37 from howarth at nitro dot med dot uc dot edu  2009-11-23 15:26 -------
> (In reply to comment #36)
> > If it's valid dwarf then it is also dwarf-strict.  Please get apple
> > fix its tools and issue a maintainance update.  (I'm inclined to close
> > this bug as invalid)
> > 
> > Richard.
> > 
> 
> Apple will be fixing this for Xcode 3.2.x, but realistically it extremely
> unlikely
> that the fix will be backported to Xcode 3.1.x or early so you are basically
> cutting off all releases earlier than Snow Leopard from generating
> complete debug code in gcc trunk. Currently we can't generate dSYM's for...
> 
>  libgcj.dylib
>  libgcjgc.1.dylib
>  libgfortran.3.dylib
>  libgomp.1.dylib
>  libobjc-gnu.2.dylib
> libssp.0.dylib
>  libstdc++.6.dylib
> 
> because of this issue. Our only other choice left will be to carry around
> non-standard patches to avoid
> this problem in distributed FSF gcc binaries for darwin.

As this only affects GCC 4.5 it is not unreasonable to require
an up-to-date Xcode.

Richard.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #39 from howarth at nitro dot med dot uc dot edu  2009-11-23 15:43 -------
Normally this wouldn't be a big deal, but powerpc support stops at Leopard so
we are effectively cutting off powerpc-apple-darwin* from every properly
generating dSYMs in gcc 4.5.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[jakub at gcc dot gnu dot org]

------- Comment #40 from jakub at gcc dot gnu dot org  2009-11-23 15:49 -------
Given:

2.6.1.1.4  Empty Location Descriptions
An empty location description consists of a DWARF expression containing no
operations. It represents a piece or all of an object that is present in the
source but not in the object code (perhaps due to optimization).

I believe this is valid DWARF, and IMNSHO it is Apple's responsibility to issue
a bug fix update, GCC shouldn't be working around Apple's bugs.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[rguenther at suse dot de]

------- Comment #41 from rguenther at suse dot de  2009-11-23 16:29 -------
Subject: Re:  [4.5 Regression] dsymutil "Assertion failed
 ..."

On Mon, 23 Nov 2009, howarth at nitro dot med dot uc dot edu wrote:

> ------- Comment #39 from howarth at nitro dot med dot uc dot edu  2009-11-23 15:43 -------
> Normally this wouldn't be a big deal, but powerpc support stops at Leopard so
> we are effectively cutting off powerpc-apple-darwin* from every properly
> generating dSYMs in gcc 4.5.

So it's the responsibility of the darwin community to come up with
either a fixed dsymutil or a proper re-implementation of it.

Richard.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #42 from howarth at nitro dot med dot uc dot edu  2009-11-23 16:35 -------
(In reply to comment #41)
> So it's the responsibility of the darwin community to come up with
> either a fixed dsymutil or a proper re-implementation of it.
> 
> Richard.
> 

Unfortunately, dsymutil isn't part of Apple's open source releases so
realistically we will just have to add a hack like comment 30 for
distributed binary builds of FSF gcc in MacPorts and fink (if we
want to be able to be able to debug code that triggers this issue
on darwin9 and earlier).


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[andreast at gcc dot gnu dot org]

------- Comment #43 from andreast at gcc dot gnu dot org  2009-11-23 20:55 -------
I understood Jack this way that he asked/is looking for a temporary solution to
prove that this is the only issue we face with dsymutil. It is not the idea,
from my understanding, that we, gcc, 'fix'/tweak gcc to workaround OS issues.
Right now, my expectation is this, Apple has to fix this issue on both,
Xcode-3.1x (Leopard) and Xcode-3.2x(Snow Leopard). There are a lot of users
which are still on Xcode-3.1x, and a few will stay on this release since they
can not upgrade due to the fact that Snow Leopard does not run on ppc machines.

>From the technical POV we should try to help isolating the issue.

My 2 cents.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #44 from howarth at nitro dot med dot uc dot edu  2009-11-23 21:41 -------
(In reply to comment #43)

> From the technical POV we should try to help isolating the issue.
> 
> My 2 cents.
> 

Actually, if the Alexandre's patch...

http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01292.html

is approved, the issue will disappear.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #45 from howarth at nitro dot med dot uc dot edu  2009-11-24 13:09 -------
Created an attachment (id=19109)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19109&action=view)
assembly for problem object file in libssp.0.dylib that causes dsymutil to
assert

/sw/src/fink.build/gcc45-4.4.999-20091123/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc45-4.4.999-20091123/darwin_objdir/./gcc/
-B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/bin/
-B/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/lib/ -isystem
/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/include -isystem
/sw/lib/gcc4.5/x86_64-apple-darwin10.2.0/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.5-20091123/libssp -Wall -g -O2 -MT ssp.o -MD -MP -MF
.deps/ssp.Tpo -dM --save-temps -c -o ssp.o
../../../gcc-4.5-20091123/libssp/ssp.c


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[jakub at redhat dot com]

------- Comment #46 from jakub at redhat dot com  2009-11-24 13:11 -------
Subject: Re:  [4.5 Regression] dsymutil "Assertion failed ..."

> assembly for problem object file in libssp.0.dylib that causes dsymutil to
> assert

You forgot -dA, without that it is not very readable.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[jakub at gcc dot gnu dot org]

------- Comment #47 from jakub at gcc dot gnu dot org  2009-11-24 13:40 -------
Also, Alex is probably far more interested in preprocessed source plus exact
cc1 options rather than assembly, because the former can be debugged a cross
compiler.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #48 from howarth at nitro dot med dot uc dot edu  2009-11-24 13:57 -------
Unfortunately, I won't be able to provide additional files until tonight.
However, looking at the ssp.s, I am wondering if the entries in the...

        .section __DWARF,__debug_loc,regular,debug
Ldebug_loc0:

section with...

        .quad   0x0
        .quad   0x0

would end up generating AT_locations of zero in the dwarf output. Those two
lines seemed to be repeated regularly in the debug section.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #49 from howarth at nitro dot med dot uc dot edu  2009-11-24 14:10 -------
I should also note that the ssp.s was generated using gcc trunk with
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html. The generated
libssp.0.dylib asserts dsymutil. Out of the object files contained in
libssp.0.dylib, only ssp.o alone causes dsymutil to assert. 


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #50 from howarth at nitro dot med dot uc dot edu  2009-11-24 19:22 -------
Created an attachment (id=19111)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19111&action=view)
output from /usr/bin/dwarfdump --verbose --show-form ssp.o

See...

http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01369.html

for an details on how to identify the zero AT_Locations in a dwarfdump from the
current devtools on darwin.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #51 from howarth at nitro dot med dot uc dot edu  2009-11-24 22:21 -------
Created an attachment (id=19114)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19114&action=view)
ssp.s generated with -dA


-- 

howarth at nitro dot med dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #19109|0                           |1
        is obsolete|                            |


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #52 from howarth at nitro dot med dot uc dot edu  2009-11-24 22:22 -------
Created an attachment (id=19115)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19115&action=view)
preprocessed source for ssp.c created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #53 from howarth at nitro dot med dot uc dot edu  2009-11-24 23:40 -------
Created an attachment (id=19116)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19116&action=view)
assembly with -dA for problem file in libgfortran dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #54 from howarth at nitro dot med dot uc dot edu  2009-11-24 23:45 -------
Created an attachment (id=19117)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19117&action=view)
assembly with -dA for problem file in libgfortran dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #55 from howarth at nitro dot med dot uc dot edu  2009-11-24 23:48 -------
Created an attachment (id=19118)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19118&action=view)
assembly with -dA for problem file in libgfortran dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #56 from howarth at nitro dot med dot uc dot edu  2009-11-24 23:53 -------
Created an attachment (id=19119)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19119&action=view)
assembly with -dA for problem file in libgfortran dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #57 from howarth at nitro dot med dot uc dot edu  2009-11-24 23:56 -------
Created an attachment (id=19120)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19120&action=view)
assembly with -dA for problem file in libgfortran dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #58 from howarth at nitro dot med dot uc dot edu  2009-11-24 23:58 -------
Created an attachment (id=19121)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19121&action=view)
assembly with -dA for problem file in libgfortran dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #59 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:03 -------
Created an attachment (id=19122)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19122&action=view)
assembly with -dA for problem file in libstdc++-v3 dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #60 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:04 -------
Created an attachment (id=19123)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19123&action=view)
assembly with -dA for problem file in libstdc++-v3 dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #61 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:07 -------
Created an attachment (id=19124)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19124&action=view)
assembly with -dA for problem file in libstdc++-v3 dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #62 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:09 -------
Created an attachment (id=19125)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19125&action=view)
assembly with -dA for problem file in libstdc++-v3 dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #63 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:12 -------
Created an attachment (id=19126)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19126&action=view)
assembly with -dA for problem file in libstdc++-v3 dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #64 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:16 -------
Created an attachment (id=19127)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19127&action=view)
preprocessed source for ios_init.cc created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #65 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:17 -------
Created an attachment (id=19128)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19128&action=view)
preprocessed source for hash_tr1.cc created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #66 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:18 -------
Created an attachment (id=19129)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19129&action=view)
preprocessed source for future.cc created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #68 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:20 -------
Created an attachment (id=19131)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19131&action=view)
preprocessed source for atomic.cc created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #67 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:19 -------
Created an attachment (id=19130)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19130&action=view)
preprocessed source for ext-inst.cc created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #69 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:22 -------
Created an attachment (id=19132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19132&action=view)
preprocessed source for write.c created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #70 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:22 -------
Created an attachment (id=19133)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19133&action=view)
preprocessed source for unix.c created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #71 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:23 -------
Created an attachment (id=19134)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19134&action=view)
preprocessed source for string_intrinsics.c created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #72 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:24 -------
Created an attachment (id=19135)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19135&action=view)
preprocessed source for random.c created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #73 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:25 -------
Created an attachment (id=19136)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19136&action=view)
preprocessed source for list_read.c created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #74 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:25 -------
Created an attachment (id=19137)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19137&action=view)
preprocessed source for erfc_scaled.c created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #75 from howarth at nitro dot med dot uc dot edu  2009-11-25 00:27 -------
The attached assembly (with -dA) and preprocessed source files should cover all
the instances of zero AT_locations currently being emitted on darwin.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #76 from howarth at nitro dot med dot uc dot edu  2009-11-25 01:11 -------
Created an attachment (id=19138)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19138&action=view)
assembly with -dA for problem file in libgfortran dylib


-- 

howarth at nitro dot med dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #19118|0                           |1
        is obsolete|                            |


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #77 from howarth at nitro dot med dot uc dot edu  2009-11-25 04:12 -------
Created an attachment (id=19141)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19141&action=view)
assembly with -dA for problem file in libgcj dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #78 from howarth at nitro dot med dot uc dot edu  2009-11-25 04:13 -------
Created an attachment (id=19142)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19142&action=view)
preprocessed source for darwin.cc created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #79 from howarth at nitro dot med dot uc dot edu  2009-11-25 04:19 -------
Created an attachment (id=19143)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19143&action=view)
assembly with -dA for problem file in libgcj dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #80 from howarth at nitro dot med dot uc dot edu  2009-11-25 04:20 -------
Created an attachment (id=19144)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19144&action=view)
preprocessed source for ltdl.c created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #81 from howarth at nitro dot med dot uc dot edu  2009-11-25 04:29 -------
Created an attachment (id=19145)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19145&action=view)
assembly with -dA for problem file in libobjc dylib


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #82 from howarth at nitro dot med dot uc dot edu  2009-11-25 04:30 -------
Created an attachment (id=19146)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19146&action=view)
preprocessed source for sendmsg.c created on x86_64-apple-darwin10


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #83 from howarth at nitro dot med dot uc dot edu  2009-11-25 04:32 -------
I believe these are all of the files generating zero AT_locations when gcc
trunk is built with the proposed patch from
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html on
x86_64-apple-darwin10.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #84 from howarth at nitro dot med dot uc dot edu  2009-11-25 17:55 -------
One other comment. The dsymutil maintainer pointed out that in those cases
where zero AT_locations exist for the dwarf block forms, even if dsymutil
doesn't assert, it will still hose the resulting debug information it
generates. So the problem is a bit worse than just the instances where dsymutil
crashes. For darwin9 or earlier we really need to completely inhibit emitting
null AT_locations for dwarf block forms.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #85 from howarth at nitro dot med dot uc dot edu  2009-11-26 22:35 -------
Created an attachment (id=19160)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19160&action=view)
combined patch that fixes dsymutil asserts

Combined patches...

http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01452.html

with hand merge of section...

@@ -15719,17 +15705,19 @@ add_location_or_const_value_attribute (d
      a constant value.  That way we are better to use
add_const_value_attribute
      rather than expanding constant value equivalent.  */
   loc_list = lookup_decl_loc (decl);
-  if (loc_list && loc_list->first && loc_list->first == loc_list->last)
+  if (loc_list && loc_list->first && loc_list->first == loc_list->last
+      && loc_list->first->var_loc_note
+      && NOTE_VAR_LOCATION (loc_list->first->var_loc_note)
+      && NOTE_VAR_LOCATION_LOC (loc_list->first->var_loc_note))
     {
       enum var_init_status status;
       struct var_loc_node *node;

       node = loc_list->first;
       status = NOTE_VAR_LOCATION_STATUS (node->var_loc_note);
-      rtl = NOTE_VAR_LOCATION (node->var_loc_note);
-      if (GET_CODE (rtl) == VAR_LOCATION
-         && GET_CODE (XEXP (rtl, 1)) != PARALLEL)
-       rtl = XEXP (XEXP (rtl, 1), 0);
+      rtl = NOTE_VAR_LOCATION_LOC (node->var_loc_note);
+      if (GET_CODE (rtl) != PARALLEL)
+       rtl = XEXP (rtl, 0);
       if ((CONSTANT_P (rtl) || GET_CODE (rtl) == CONST_STRING)
          && add_const_value_attribute (die, rtl))
         return true;

against current gcc trunk. This patch eliminates all of the asserts in dsymutil
during a bootstrap of gcc trunk.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #86 from howarth at nitro dot med dot uc dot edu  2009-11-27 00:07 -------
Checking all of the object files in a build of gcc trunk with the combined
proposed patches from comment 85 with...

/usr/bin/dwarfdump --verbose --show-form *.o | grep -C5
'AT_location.*FORM_block[^<]' | grep 0x0000000000000000 | grep breg7

that picks of the current representation of null AT locations in the shipping
dwarfdump reveals that none of the object files now have these dwarf codes
emitted into them. So the fix appears to be complete.
Note that these null AT locations currently would appear in dwarfdump as...

0x000004cf:     TAG_variable [20]  
0x000004d0:      AT_name[FORM_string] ( "darwin_constructor" )
0x000004e3:      AT_decl_file[FORM_data1] ( 0x01 (
"/sw/src/fink.build/gcc45-4.4.999-20091123/gcc-4.5-20091123/libjava/darwin.cc"
) )
0x000004e4:      AT_decl_line[FORM_data1] ( 0x50 ( 80 ) )
0x000004e5:      AT_type[FORM_ref4] ( cu + 0x00000264 => {0x00000264} (
darwin_constructor_s ) )
0x000004e9:      AT_location[FORM_block1] ( 
                    0x0000000000000000 - 0x0000000000000001: breg7 +8
                    0x0000000000000001 - 0x0000000000000016: breg7 +16
                    0x0000000000000016 - 0x000000000000003b: breg7 +32
                    0x000000000000003b - 0x000000000000003c: breg7 +16
                    0x000000000000003c - 0x000000000000003d: breg7 +8 )

if present.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #87 from dominiq at lps dot ens dot fr  2009-11-28 18:40 -------
With the combined proposed patches from comment 85, I do not see anymore
dsymutil failures on (powerpc|i686)-apple-darwin9 and x86_64-apple-darwin10.

>From the failures in comment #8, I have noticed that 'gcc -g *' calls dsymutil,
while neither 'gcc -g * -lm', nor 'gfortran -g *' call it. Is it the intended
behavior?

Last remark, I have called dsymutil for ~2000 fortran test and a few of them
gives:

warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item
TAG_subrange_type: attr =  AT_upper_bound  form = FORM_ref4

Any comment about this warning?


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #88 from howarth at nitro dot med dot uc dot edu  2009-11-28 18:45 -------
Do you see this in gcc 4.4.2 as well? I would suggest trying to find
a minimal test case that produces the warning from dsymutil and then
open a new radar with the preprocessed source and the assembly generated
with -dA for Apple to review. It may be harmless noise from dsymutil
but we should definitely get it removed for the next Xcode release.
                  Jack


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #89 from dominiq at lps dot ens dot fr  2009-11-28 19:04 -------
> Do you see this in gcc 4.4.2 as well?

No. A test case is

[ibook-dhum] f90/bug% cat pr34231.f90
MODULE test

   TYPE odbase ; INTEGER :: value ; END TYPE

   INTERFACE odfname
      MODULE PROCEDURE odfamilycname,odfamilycnames
   END INTERFACE

   CONTAINS

   SUBROUTINE odfamilycnames(base,nfam,cnames)
      TYPE(odbase),INTENT(in)  :: base
      INTEGER     ,INTENT(out) :: nfam
      CHARACTER(*),INTENT(out) :: cnames(*)
      nfam=0
      cnames(1:nfam)=' '
      write(*,*) 'odfamilycnames'
   END SUBROUTINE

   SUBROUTINE odfamilycname(base,pos,cname)
      TYPE(odbase),INTENT(in)  :: base
      INTEGER     ,INTENT(in)  :: pos
      CHARACTER(*),INTENT(out) :: cname
      cname=' '
      write(*,*) 'odfamilycname'
   END SUBROUTINE

END MODULE

PROGRAM main
  USE test
  TYPE(odbase) :: base
  INTEGER :: i=1
  CHARACTER(8) :: cname
  CALL odfname(base,i,cname)
END PROGRAM
ibook-dhum] f90/bug% gfc -c -o pr34231.o -O3 -g pr34231.f90
[ibook-dhum] f90/bug% gfc pr34231.o
[ibook-dhum] f90/bug% dsymutil a.out 
warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item
TAG_subrange_type: attr =  AT_upper_bound  form = FORM_ref4
[ibook-dhum] f90/bug% gfc44 -c -o pr34231.o -O3 -g pr34231.f90
[ibook-dhum] f90/bug% gfc44 pr34231.o
[ibook-dhum] f90/bug% dsymutil a.out
[ibook-dhum] f90/bug% 


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #90 from howarth at nitro dot med dot uc dot edu  2009-11-28 19:07 -------
Since dsymutil isn't asserting, I wouldn't be so worried unless the test cases
start to fail. Do file a radar though with at least assembly with -dA so that
Apple can review what is happening.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #91 from dominiq at lps dot ens dot fr  2009-12-03 13:27 -------
Is there any reason why the patch in commen #85 has not been commited? 
As stressed by Jack Howarth in
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00096.html, it is critical for
darwin and probably good for other platforms as well.


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[jakub at gcc dot gnu dot org]

------- Comment #92 from jakub at gcc dot gnu dot org  2009-12-07 17:15 -------
The patches weren't reviewed/approved.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #93 from howarth at nitro dot med dot uc dot edu  2009-12-07 18:25 -------
(In reply to comment #92)
> The patches weren't reviewed/approved.
> 

Jakub,
    Could you review and approve the patches then?


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[jakub at gcc dot gnu dot org]

------- Comment #94 from jakub at gcc dot gnu dot org  2009-12-07 18:30 -------
No, a quick look into MAINTAINERS could tell you that as this has nothing to do
with OpenMP, isn't a gimplifier patch nor has anything to do with SPARC, I
can't approve it.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[howarth at nitro dot med dot uc dot edu]

------- Comment #95 from howarth at nitro dot med dot uc dot edu  2009-12-07 18:40 -------
(In reply to comment #94)
> No, a quick look into MAINTAINERS could tell you that as this has nothing to do
> with OpenMP, isn't a gimplifier patch nor has anything to do with SPARC, I
> can't approve it.
> 

So other than a global reviewer, we need Jason Merrill to review it, right?


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[jakub at gcc dot gnu dot org]

------- Comment #96 from jakub at gcc dot gnu dot org  2009-12-14 16:55 -------
Subject: Bug 41473

Author: jakub
Date: Mon Dec 14 16:55:12 2009
New Revision: 155221

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155221
Log:
        PR debug/41473
        * dwarf2out.c (add_var_loc_to_decl): Don't drop initial empty
        locations.
        (new_loc_list): Drop gensym arg.  Move generation of ll_symbol...
        (gen_llsym): ... here.  New function.
        (add_loc_descr_to_loc_list): Removed.
        (loc_descriptor): Infer mode from CONST_DOUBLEs and CONST_VECTORs.
        (single_element_loc_list): Removed.
        (dw_loc_list): Don't create entries without a location.  Don't
        special-case the first node of the list, only single nodes.
        (single_element_loc_list_p): Simplify.
        (loc_list_from_tree): Don't use DECL_RTL if loc_list is nonempty.
        (add_location_or_const_value_attribute): Test var loc for NULL.
        (convert_cfa_to_fb_loc_list): Adjust calls to new new_loc_list,
        call gen_llsym if needed.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[jakub at gcc dot gnu dot org]

------- Comment #97 from jakub at gcc dot gnu dot org  2009-12-14 16:56 -------
Subject: Bug 41473

Author: jakub
Date: Mon Dec 14 16:55:52 2009
New Revision: 155222

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155222
Log:
        PR debug/41473
        * dwarf2out.c (AT_loc_list_ptr): New.
        (resolve_addr): Remove unresolved attributes and loc_list entries.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dwarf2out.c


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[developer at sandoe-acoustics dot co dot uk]

------- Comment #98 from developer at sandoe-acoustics dot co dot uk  2009-12-14 18:31 -------
i686-apple-darwin9 bootstraps without dsymutil fails at 155225, thanks Jakub.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[dominiq at lps dot ens dot fr]

------- Comment #99 from dominiq at lps dot ens dot fr  2009-12-15 10:14 -------
> i686-apple-darwin9 bootstraps without dsymutil fails at 155225, thanks Jakub.

powerpc-apple-darwin9 too at 155239. For x86_64-apple-darwin10, I think the
problem is fixed too, but between revisions 154996 and 155016 (likely 155012)
libtool stopped to call dsymutil (any idea about that? should I open a new pr
for it?).

If there is no objection, I'll close the PR as fixed in a few days.

Thanks all for debugging and fixing the problem.


-- 


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

[Bug target/41473] [4.5 Regression] dsymutil "Assertion failed ..."

[jakub at gcc dot gnu dot org]

------- Comment #100 from jakub at gcc dot gnu dot org  2009-12-16 13:27 -------
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

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


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