Pruning for torture tests?

[IainS]

Hi,
On Darwin, we have a number of gcc.c-torture fails reported for both  
ppc and i386 which are bogus (nothing to do with gcc - but simply  
warning output from a system tool).


For dg-based tests these are pruned - I wonder if it would be worth  
adding a prune capability to the torture suites?


opinions?
Iain

Re: Pruning for torture tests?

[IainS]

Hi Rainer,

On 23 Mar 2011, at 18:45, Rainer Orth wrote:


On Darwin, we have a number of gcc.c-torture fails reported for  
both ppc
and i386 which are bogus (nothing to do with gcc - but simply   
warning

output from a system tool).

For dg-based tests these are pruned - I wonder if it would be worth  
adding

a prune capability to the torture suites?


IMO this is the wrong approach.  I'd like us to move away from the
non-dg testsuites if at all possible.


I personally agree...

... but when I suggested this for the (relatively small) ObjC set of  
torture tests, it was not greeted enthusiastically...


(the  problem voiced,  IIRC, is of maintaining audit history of test  
pass/fails)


... I'd imagine that this would be amplified 100x for the other  
torture suites.


Iain

darwin8 / ppc bootstrap is failing for me.

[IainS]

 uname -mrs
Darwin 8.11.0 Power Macintosh

../gcc-4-5-regtest/configure --prefix=/Volumes/ScratchCS/gcc-4-5- 
install --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- 
build=powerpc-apple-darwin8 --enable-languages=c,objc,c++,obj-c+ 
+,fortran --enable-version-specific-runtime-libs --enable-threads -- 
enable-checking=yes --program-suffix=-4.5.0 --with-dwarf2 --with- 
libiconv-prefix=/usr --with-system-zlib


make bootstrap >build-log.txt 2>err-log.txt &

fails:

configure: WARNING: decimal float is not supported for this target
configure: WARNING: fixed-point is not supported for this target
configure: error: in `/Volumes/ScratchCS/gcc-4-5-regbuild/gcc':
Links are now set up to build a native compiler for powerpc-apple- 
darwin8.

In file included from ../../gcc-4-5-regtest/libiberty/regex.c:638:0:
../../gcc-4-5-regtest/libiberty/regex.c: In function  
'byte_re_match_2_internal':
../../gcc-4-5-regtest/libiberty/regex.c:7476:5: warning: jump skips  
variable initialization
../../gcc-4-5-regtest/libiberty/regex.c:5952:12: note: label  
'restore_best_regs' defined here
../../gcc-4-5-regtest/libiberty/regex.c:5913:16: note: 'same_str_p'  
declared here

configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.
make[2]: *** [configure-stage2-gmp] Error 1
make[1]: *** [stage2-bubble] Error 2
make: *** [bootstrap] Error 2

cheers,
Iain

Re: darwin8 / ppc bootstrap is failing for me.

[IainS]

Hi Ralf,

On 24 Aug 2009, at 18:47, Ralf Wildenhues wrote:


Hello Iain,

* IainS wrote on Mon, Aug 24, 2009 at 07:16:05PM CEST:

 uname -mrs
Darwin 8.11.0 Power Macintosh



configure: WARNING: decimal float is not supported for this target
configure: WARNING: fixed-point is not supported for this target
configure: error: in `/Volumes/ScratchCS/gcc-4-5-regbuild/gcc':
Links are now set up to build a native compiler for powerpc-apple- 
darwin8.

In file included from ../../gcc-4-5-regtest/libiberty/regex.c:638:0:
../../gcc-4-5-regtest/libiberty/regex.c: In function
'byte_re_match_2_internal':
../../gcc-4-5-regtest/libiberty/regex.c:7476:5: warning: jump skips
variable initialization
../../gcc-4-5-regtest/libiberty/regex.c:5952:12: note: label
'restore_best_regs' defined here
../../gcc-4-5-regtest/libiberty/regex.c:5913:16: note: 'same_str_p'
declared here
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.
make[2]: *** [configure-stage2-gmp] Error 1
make[1]: *** [stage2-bubble] Error 2
make: *** [bootstrap] Error 2


Please inspect and/or show the relevant parts of
  /Volumes/ScratchCS/gcc-4-5-regbuild/gcc/config.log


BTW  - I should have said current trunk:
Updating SVN tree
At revision 151057.
Adjusting file timestamps

==

the configure that's failing is GMP rather than gcc...  maybe I've  
missed a requirement to update?


the essence appears to be this - it looks like some issue with path  
definitions :


| # include 
| #else
| # include 
| #endif
|Syntax error
configure:11139: /lib/cpp -DNO_ASM conftest.cc
/Volumes/ScratchCS/gcc-4-5-regtest/gmp/configure: line 1: /lib/cpp:  
No such file or directory

configure:11145: $? = 127
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME "GNU MP"
| #define PACKAGE_TARNAME "gmp"
| #define PACKAGE_VERSION "4.2.4"
| #define PACKAGE_STRING "GNU MP 4.2.4"
| #define PACKAGE_BUGREPORT "gmp-b...@swox.com"
| #define PACKAGE "gmp"
| #define VERSION "4.2.4"
| #define WANT_FFT 1
| #define HAVE_HOST_CPU_none 1
| #define PROTOTYPES 1
| #define __PROTOTYPES 1
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_STRING_H 1
| #define HAVE_DLFCN_H 1
| /* end confdefs.h.  */
| #ifdef __STDC__
| # include 
| #else
| # include 
| #endif
|Syntax error
configure:11214: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

cheers,
Iain

Re: darwin8 / ppc bootstrap is failing for me.

[IainS]

Thanks Ralf,

On 24 Aug 2009, at 19:52, Ralf Wildenhues wrote:


* IainS wrote on Mon, Aug 24, 2009 at 08:17:37PM CEST:


the configure that's failing is GMP rather than gcc...  maybe I've
missed a requirement to update?



configure:11139: /lib/cpp -DNO_ASM conftest.cc
/Volumes/ScratchCS/gcc-4-5-regtest/gmp/configure: line 1: /lib/cpp:
No such file or directory


configure:11214: error: C++ preprocessor "/lib/cpp" fails sanity  
check

See `config.log' for more details.


Maybe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40950 or similar?
Anyway, the error happens even earlier, probably when it's trying to
find an in-tree C++ compiler.



That seems to be it, and the cure is to add --enable-stage1- 
languages=c,c++ (as per the bugreport).


In fact, it seems to effect both Darwin8 & 9 when building in-tree  
GMP (so possibly others too).


The problem appeared between 148251 and 151057 (yeah, a big gap I  
know.. busy with other things).


Note that I haven't changed the GMP - so the fail *is* as a result of  
some aspect of the gcc build process changing.

presumably, most likely the upgrade in auto* tools.

I'll add a comment to the bugreport when the darwin9 build finishes.

thanks again,
Iain

bootstrap fail on powerpc-apple-darwin8

[IainS]

uname -prs
Darwin 8.11.0 powerpc

Updating SVN tree
At revision 151374.

config:
 ../gcc-4-5-regtest/configure --prefix=/Volumes/ScratchCS/gcc-4-5- 
install --target=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- 
build=powerpc-apple-darwin8 --enable-languages=c,objc,c++,obj-c+ 
+,fortran --enable-version-specific-runtime-libs --enable-threads -- 
enable-checking=yes --program-suffix=-4.5.0 --with-dwarf2 --with- 
libiconv-prefix=/usr --with-system-zlib --enable-stage1-languages=c,c++


output:

[address=03d770b0 pc=002cabf8]
../../gcc-4-5-regtest/gcc/config/rs6000/altivec.md: In function  
'recog_48':
../../gcc-4-5-regtest/gcc/config/rs6000/altivec.md:1864:1: internal  
compiler error: Segmentation Fault

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [insn-recog.o] Error 1
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [bootstrap] Error 2

what other output would hep diagnose this?
(151057 was my last successful bootstrap)
Iain

[4.5 bootstrap] i686-apple-darwin9 broken at 151839?

[IainS]

$ uname -v
Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;  
root:xnu-1228.15.4~1/RELEASE_I386


$ more stage_current
stage3

superficial error is:
$ make -j8 bootstrap >build-log.txt 2>err-log.txt
$ tail err-log.txt
configure: error: cannot compute sizeof (long long)See `config.log'  
for more details.

make[2]: *** [configure-stage3-gcc] Error 77
make[2]: *** Waiting for unfinished jobs

but it seems that the real problem might be ( a lot of these in the  
config log) :


Assertion failed: (!"Unknown one-operand"), function LinkLocation,  
file /SourceCache/dwarf_utilities/dwarf_utilities-49/source/ 
DWARFdSYM.cpp, line 1457.

xgcc: Internal error: Abort trap (program dsymutil)
Please submit a full bug report.

 here is the specific long long case...

configure:5749: checking size of long long
configure:5754:  /Volumes/ScratchCS/gcc-4-5-reg-build/./prev-gcc/xgcc - 
B/Volumes/ScratchCS/gcc-4-5-reg-build/./prev-gcc/ -B/Volumes/Scrat
chCS/gcc-4-5-install/i686-apple-darwin9/bin/ -B/Volumes/ScratchCS/ 
gcc-4-5-install/i686-apple-darwin9/bin/ -B/Volumes/ScratchCS/gcc-4-5-in
stall/i686-apple-darwin9/lib/ -isystem /Volumes/ScratchCS/gcc-4-5- 
install/i686-apple-darwin9/include -isystem /Volumes/ScratchCS/gcc-4-5-
install/i686-apple-darwin9/sys-include-o conftest -g -O2 -fomit- 
frame-pointerconftest.c  >&5
Assertion failed: (!"Unknown one-operand"), function LinkLocation,  
file /SourceCache/dwarf_utilities/dwarf_utilities-49/source/DWARFdSYM.

cpp, line 1457.
xgcc: Internal error: Abort trap (program dsymutil)
Please submit a full bug report.
See  for instructions.
configure:5754: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define HAVE_GNU_LD 0
| #define HAVE_GNU_AS 0
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define SIZEOF_VOID_P 0
| #define SIZEOF_SHORT 0
| #define SIZEOF_INT 0
| #define SIZEOF_LONG 0
| #define HAVE_LONG_LONG 1
| /* end confdefs.h.  */
| #include 
| #ifdef HAVE_SYS_TYPES_H
| # include 
| #endif
| #ifdef HAVE_SYS_STAT_H
| # include 
| #endif
| #ifdef STDC_HEADERS
| # include 
| # include 
| #else
| # ifdef HAVE_STDLIB_H
| #  include 
| # endif
| #endif
| #ifdef HAVE_STRING_H
| # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
| #  include 
| # endif
| # include 
| #endif
| #ifdef HAVE_STRINGS_H
| # include 
| #endif
| #ifdef HAVE_INTTYPES_H
| # include 
| #endif
| #ifdef HAVE_STDINT_H
| # include 
| #endif
| #ifdef HAVE_UNISTD_H
| # include 
| #endif
| static long int longval () { return (long int) (sizeof (long long)); }
| static unsigned long int ulongval () { return (long int) (sizeof  
(long long)); }

| #include 
| #include 
| int
| main ()
| {
|
|   FILE *f = fopen ("conftest.val", "w");
|   if (! f)
| return 1;
|   if (((long int) (sizeof (long long))) < 0)
| {
|   long int i = longval ();
|   if (i != ((long int) (sizeof (long long
|   return 1;
|   fprintf (f, "%ld", i);
| }
|   else
| {
|   unsigned long int i = ulongval ();
|   if (i != ((long int) (sizeof (long long
|   return 1;
|   fprintf (f, "%lu", i);
| }
|   /* Do not output a trailing newline, as this causes \r\n confusion
|  on some platforms.  */
|   return ferror (f) || fclose (f) != 0;
|
|   ;
|   return 0;
| }
configure:5758: error: in `/Volumes/ScratchCS/gcc-4-5-reg-build/gcc':
configure:5762: error: cannot compute sizeof (long long)
See `config.log' for more details.



anyone else seeing this?
Iain

the Right place to change a target default for a common compiler flag?

[IainS]

Hi,

In the case that a compiler flag in common.opt would best be served  
with different default values on different targets.


I.E. a target-dependent Init()

Where can this be effected in the machinery ?

I can see how to make an override - but not a default.

cheers,
Iain

Re: the Right place to change a target default for a common compiler flag?

[IainS]

Hi Dominique,

I would expect you to need  -gstrict-dwarf in CFLAGS_FOR_TARGET also

but the point of my question is to find a way of having this on by  
default on Darwin (which is what we currently seem to need).


(more research is need on the latter - to determine whether the  
problem lies in our emission of debug fragments - or in the tools


cheers,
Iain

On 23 Sep 2009, at 14:42, Dominique Dhumieres wrote:


Iain,

I am currently bootstrapping on i686-apple-darwin9 with the current  
patch:


diff -uN /opt/gcc/_gcc_clean/config/mh-intel-darwin /opt/gcc/ 
gcc-4.5-work/config/mh-intel-darwin
--- /opt/gcc/_gcc_clean/config/mh-intel-darwin	1970-01-01  
01:00:00.0 +0100
+++ /opt/gcc/gcc-4.5-work/config/mh-intel-darwin	2009-09-23  
13:47:12.0 +0200

@@ -0,0 +1,3 @@
+# Set strict-dwarf for Darwin
+
+BOOT_CFLAGS += -gstrict-dwarf
diff -uN /opt/gcc/_gcc_clean/config/mh-ppc-darwin /opt/gcc/gcc-4.5- 
work/config/mh-ppc-darwin
--- /opt/gcc/_gcc_clean/config/mh-ppc-darwin	2008-02-25  
11:00:23.0 +0100
+++ /opt/gcc/gcc-4.5-work/config/mh-ppc-darwin	2009-09-23  
12:07:12.0 +0200

@@ -2,4 +2,4 @@
 # position-independent-code -- the usual default on Darwin. This  
fix speeds

 # compiles by 3-5%.

-BOOT_CFLAGS += -mdynamic-no-pic
+BOOT_CFLAGS += -mdynamic-no-pic -gstrict-dwarf
--- /opt/gcc/_gcc_clean/configure   2009-09-22 20:04:27.0 +0200
+++ /opt/gcc/gcc-4.5-work/configure	2009-09-23 13:50:29.0  
+0200

@@ -3655,6 +3655,12 @@
   powerpc-*-darwin*)
 host_makefile_frag="config/mh-ppc-darwin"
 ;;
+  i[3456789]86-*-darwin*)
+host_makefile_frag="config/mh-intel-darwin"
+;;
+  x86_64-*-darwin[912]*)
+host_makefile_frag="config/mh-intel-darwin"
+;;
   powerpc-*-aix*)
 host_makefile_frag="config/mh-ppc-aix"
 ;;

I am currently at stage 3 and I see -gstrict-dwarf in the log file.

I don't know if it is the Right place, but it seems to work so far.

Cheers,

Dominique

question on dwarf2 debug-frame.

[IainS]

Hello,

I have this scenario:
 using  "dwarfdump --debug-frame" in a very simple object generated  
with current trunk.
I am trying to figure out (with the dwarf3 spec) wether the problem  
is in the tool (dwarfdump), or what we're emitting.

Can anyone more knowledgeable comment?

Iain.

--
 File: simplistic.o { mach32-i386 }
--

.debug_frame contents:

0x: CIE
length: 0x0010
CIE_id: 0x
   version: 0x01
  augmentation: ""
code_align: 1
data_align: -4
   ra_register: 0x08
  Initial Inst: DW_CFA_def_cfa (4, 4)
DW_CFA_offset (8, 0)
DW_CFA_nop
DW_CFA_nop
Init State: CFA( R4+4  )   R8=+0


0x0014: FDE
length: 0x0028
   CIE_pointer: 0x
start_addr: 0x
range_size: 0x0012
  Instructions: 0x: CFA( R4+4  )   R8=+0
DW_CFA_advance_loc4 (1)
DW_CFA_def_cfa_offset (8)
DW_CFA_offset (5, -8)
0x0001: CFA( R4+8  )   R5=-8   R8=+0
DW_CFA_advance_loc4 (2)
DW_CFA_def_cfa_register (5)
0x0003: CFA( R5+8  )   R5=-8   R8=+0
DW_CFA_advance_loc4 (14)
DW_CFA_restore (5)
Assertion failed: (reg_state_pos != cie->initial_state.regs.end()),  
function ParseInstructions, file /SourceCache/dwarf_utilities/ 
dwarf_utilities-49/source/DWARFDebugFrame.cpp, line 353.

Abort trap


the -save-temps -dA output for this is:

.section __DWARF,__debug_frame,regular,debug
Lframe0:
.set L$set$0,LECIE0-LSCIE0
.long L$set$0   # Length of Common Information Entry
LSCIE0:
.long   0x  # CIE Identifier Tag
.byte   0x1 # CIE Version
.ascii "\0"   # CIE Augmentation
.byte   0x1 # uleb128 0x1; CIE Code Alignment Factor
.byte   0x7c# sleb128 -4; CIE Data Alignment Factor
.byte   0x8 # CIE RA Column
.byte   0xc # DW_CFA_def_cfa
.byte   0x4 # uleb128 0x4
.byte   0x4 # uleb128 0x4
.byte   0x88# DW_CFA_offset, column 0x8
.byte   0x1 # uleb128 0x1
.align 2
LECIE0:
LSFDE0:
.set L$set$1,LEFDE0-LASFDE0
.long L$set$1   # FDE Length
LASFDE0:
.set L$set$2,Lframe0-Lsection__debug_frame
.long L$set$2   # FDE CIE offset
.long   LFB0# FDE initial location
.set L$set$3,LFE0-LFB0
.long L$set$3   # FDE address range
.byte   0x4 # DW_CFA_advance_loc4
.set L$set$4,LCFI0-LFB0
.long L$set$4
.byte   0xe # DW_CFA_def_cfa_offset
.byte   0x8 # uleb128 0x8
.byte   0x85# DW_CFA_offset, column 0x5
.byte   0x2 # uleb128 0x2
.byte   0x4 # DW_CFA_advance_loc4
.set L$set$5,LCFI1-LCFI0
.long L$set$5
.byte   0xd # DW_CFA_def_cfa_register
.byte   0x5 # uleb128 0x5
.byte   0x4 # DW_CFA_advance_loc4
.set L$set$6,LCFI3-LCFI1
.long L$set$6
.byte   0xc5# DW_CFA_restore, column 0x5
.byte   0xc # DW_CFA_def_cfa
.byte   0x4 # uleb128 0x4
.byte   0x4 # uleb128 0x4
.align 2
LEFDE0:

further help on dwarf2 debug

[IainS]

I'm trying to formulate a bug report for tools used to examine/ 
process debug output.

looking specifically at the _debug_frame.

for this source:

---
int testfunc(void)
{
int i;
i = 1;
return i;
}

===

using -save-temps -dA -g -O0 -fverbose-asm (-gstrict-dwarf, on 4.5)

comparing the output of gcc-4-4 and trunk.

The main difference (and the area causing the tool to barf) is that  
the FDE on 4.5 has some extra information not present in 4.4


.byte   0x4 # DW_CFA_advance_loc4
.set L$set$6,LCFI3-LCFI1
.long L$set$6
.byte   0xc5# DW_CFA_restore, column 0x5
.byte   0xc # DW_CFA_def_cfa
.byte   0x4 # uleb128 0x4
.byte   0x4 # uleb128 0x4


whilst, with the aid of the dwarf3 spec, I can see that this is  
syntactically correct (and confirm that the object file contains the  
correct output).

I can't (at the moment) determine if it's logically correct.
What is the purpose of the addition?
(complete .s files attached)

TIA,
Iain

.section __DWARF,__debug_frame,regular,debug
Lsection__debug_frame:
.section __DWARF,__debug_info,regular,debug
Lsection__debug_info:
.section __DWARF,__debug_abbrev,regular,debug
Lsection__debug_abbrev:
.section __DWARF,__debug_aranges,regular,debug
Lsection__debug_aranges:
.section __DWARF,__debug_macinfo,regular,debug
Lsection__debug_macinfo:
.section __DWARF,__debug_line,regular,debug
Lsection__debug_line:
.section __DWARF,__debug_loc,regular,debug
Lsection__debug_loc:
.section __DWARF,__debug_pubnames,regular,debug
Lsection__debug_pubnames:
.section __DWARF,__debug_pubtypes,regular,debug
Lsection__debug_pubtypes:
.section __DWARF,__debug_str,regular,debug
Lsection__debug_str:
.section __DWARF,__debug_ranges,regular,debug
Lsection__debug_ranges:
# GNU C (GCC) version 4.4.1 20090516 (prerelease) [gcc-4_4-branch revision 
147621] (i686-apple-darwin9)
#   compiled by GNU C version 4.4.1 20090516 (prerelease) [gcc-4_4-branch 
revision 147621], GMP version 4.2.4, MPFR version 2.3.2.
# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
# options passed:  -fpreprocessed simplistic.i -fPIC
# -feliminate-unused-debug-symbols -mmacosx-version-min=10.5.8
# -mtune=generic -g -O0 -fverbose-asm
# options enabled:  -fPIC -falign-loops -fargument-alias -fauto-inc-dec
# -fbranch-count-reg -fcommon -fearly-inlining
# -feliminate-unused-debug-symbols -feliminate-unused-debug-types
# -ffunction-cse -fgcse-lm -fident -finline-functions-called-once
# -fira-share-save-slots -fira-share-spill-slots -fivopts
# -fkeep-static-consts -fleading-underscore -fmerge-debug-strings
# -fmove-loop-invariants -fpeephole -freg-struct-return -fsched-interblock
# -fsched-spec -fsched-stalled-insns-dep -fsigned-zeros
# -fsplit-ivs-in-unroller -ftrapping-math -ftree-cselim -ftree-loop-im
# -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops=
# -ftree-reassoc -ftree-scev-cprop -ftree-switch-conversion
# -ftree-vect-loop-version -funit-at-a-time -fvect-cost-model -fverbose-asm
# -fzero-initialized-in-bss -m128bit-long-double -m32 -m80387
# -maccumulate-outgoing-args -malign-stringops -mfancy-math-387
# -mfp-ret-in-387 -mfused-madd -mieee-fp -mmmx -mno-red-zone -mno-sse4
# -mpush-args -msahf -msse -msse2

.section __DWARF,__debug_abbrev,regular,debug
Ldebug_abbrev0:
.section __DWARF,__debug_info,regular,debug
Ldebug_info0:
.section __DWARF,__debug_line,regular,debug
Ldebug_line0:
.text
Ltext0:
# Compiler executable checksum: c0a59a01f5e2b209a6abb15a4aa91764

.globl _testfunc
_testfunc:
LFB0:
# ../tests/simplistic.c:2
LM1:
# basic block 2
pushl   %ebp#
LCFI0:
movl%esp, %ebp  #,
LCFI1:
subl$24, %esp   #,
LCFI2:
# ../tests/simplistic.c:4
LM2:
movl$1, -12(%ebp)   #, i
# ../tests/simplistic.c:5
LM3:
movl-12(%ebp), %eax # i, D.1573
# ../tests/simplistic.c:6
LM4:
leave
ret
LFE0:
.section __DWARF,__debug_frame,regular,debug
Lframe0:
.set L$set$0,LECIE0-LSCIE0
.long L$set$0   # Length of Common Information Entry
LSCIE0:
.long   0x  # CIE Identifier Tag
.byte   0x1 # CIE Version
.ascii "\0" # CIE Augmentation
.byte   0x1 # uleb128 0x1; CIE Code Alignment Factor
.byte   0x7c# sleb128 -4; CIE Data Alignment Factor
.byte   0x8 # CIE RA Column
.byte   0xc # DW_CFA_def_cfa
.byte   0x4 # uleb128 0x4
.byte   0x4 # uleb128 0x4
.byte   0x11# DW_CFA_offset_extended_sf
.byte   0x8 # uleb128 0x8
.byte   0x1 # sleb128 1
.align 2
LECIE0:
LSFDE0:
.set L$set$1,LEFDE0-LASFDE0
.long L$set$1   # FDE Length
LASFDE0:
.set L$set$2,Lframe0-Lsection__debug_frame
.long

Re: further help on dwarf2 debug

[IainS]

On 24 Sep 2009, at 10:27, Dominique Dhumieres wrote:


With revision 152076 on i686-apple-darwin9 bootstrapped as described
in comment#61 of pr41405, I get:

[ibook-dhum] bug/debug% gcc45 -c -save-temps -dA -g -O0 -fverbose- 
asm -gno-strict-dwarf simplistic.c

[ibook-dhum] bug/debug% dwarfdump --debug-frame simplistic.o
--
 File: simplistic.o (i386)
--
.debug_frame contents:





   DW_CFA_nop
DW_CFA_nop
0x0011: CFA=esp+4 ebp=[esp-4]  eip=[esp+4]
(same result with -gstrict-dwarf).


So, this particular bug appears to be cleared at

dwarfutils-66  or greater.  (confirmed at dwarfutils-70 as well)

(It does not seem to affect powerpc-apple-darwin8 which only has  
dwarfutils-42,

 but I can't speak for i686-apple-darwin-8)

Thanks.  I'll now start to try and track down the orig_sym one.

Following Jakub Jelinek's advice (sorry I cannot find the post) I  
have tried the

tests in gcc/testsuite/gcc.dg/guality/, but did not get any failure.


I'm currently regtesting 152114/i686-apple-darwin9 with my default  
gstrict-dwarf patch and -g{no-,)gstrict-dwarf.


Iain

Re: further help on dwarf2 debug

[IainS]

On 24 Sep 2009, at 15:54, Jack Howarth wrote:


On Thu, Sep 24, 2009 at 03:01:12PM +0100, IainS wrote:


So, this particular bug appears to be cleared at


Iain,
   What do you mean by the 'bug appears to be cleared'? Can you
map which versions of Xcode on Intel darwin exhibit this bug
and which don't?



this bug - "fail in dwarfdump --debug-frame" for i686 target

Is present in:
XCode 3.1.2 dwarfutils-49 (IIRC)

In not present in:
XCode 3.1.3  dwarfutils-66 and XCode 3.1.4 dwarfutils-70

--
N.B. this is NOT the "orig_str" Abort in dsymutil (still present in  
library builds on all versions of darwin I've tried).


Iain

libgcc rpaths with --enable-version-specific-runtime-libs

[IainS]

when libgcc multilibs are built the Makefile forces two vars to be  
empty during the build phase viz:


  slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)

unfortunately, "libsubdir" is used in configure.ac like this.

AC_ARG_WITH(slibdir,
[  --with-slibdir=DIR  shared libraries in DIR [LIBDIR]],
slibdir="$with_slibdir",
if test "${version_specific_libs}" = yes; then
  slibdir='$(libsubdir)'
elif test -n "$with_cross_host" && test x"$with_cross_host" != x"no";  
then

  slibdir='$(exec_prefix)/$(host_noncanonical)/lib'
else
  slibdir='$(libdir)'
fi)
AC_SUBST(slibdir)

and slibdir :
shlib_slibdir = @slibdir@

and shlib_slibdir ends up as the path for the instal_name (via  
shlib_slibdir expansion in the LINK fragment).


== the upshot is that (at least on dawin) when building with "-- 
enable-version-specific-runtime-libs"


libgcc gets built with

/libgcc_s.1.dylib

as the embedded rpath

This then gets referenced by the other libs (e.g. libgfortran.dylib)  
[ because the stub libs 10.X refer to it].


Whilst the libgcc path is corrected in the install phase; the  
references in the other libraries are not.




libsubdir is expanded
libsubdir = $(libdir)/gcc/$(host_noncanonical)/$(version)

in Makefile.in.

If this expansion is applied in configure.ac,  all works OK on darwin.
i.e.
if test "${version_specific_libs}" = yes; then
  slibdir='$(libdir)/gcc/$(host_noncanonical)/$(version)'

Would that change cause a problem on any other target?

Iain

help with debugging issues running the gcc.dg/guality tests.

[IainS]

Hi.
On Darwin we've got some difficulties with the guality testsuite  
components.


first there are a couple of changes needed to get the basic  
check_gualityXXX.exe to run
(a) we have to detect Darwin in the same category as unix for the  
redirect.

(b) we need "-save-temps" to find the debug info.
no problem

now the check runs :

e-temps  -lm   -o guality_check55078.exe(timeout = 300)
spawn /gcc-4-5-reg-build/gcc/xgcc -B/gcc-4-5-reg-build/gcc/  
guality_check55078.c -g -O0 -save-temps -lm -o guality_check55078.exe
Setting LD_LIBRARY_PATH to :/gcc-4-5-reg-build/gcc::/gcc-4-5-reg- 
build/gcc

spawn [open ...]
PASS: varl is 6
PASS: 1 PASS, 0 FAIL, 0 UNRESOLVED

OK.. but then the next check

Executing on host: /gcc-4-5-reg-build/gcc/xgcc -B/gcc-4-5-reg-build/ 
gcc/ /gcc-4-5-regtest/gcc/testsuite/gcc.dg/guality/example.c   -O0  - 
g -save-temps  -lm   -o ./example.exe(timeout = 300)
spawn /gcc-4-5-reg-build/gcc/xgcc -B/gcc-4-5-reg-build/gcc/ /gcc-4-5- 
regtest/gcc/testsuite/gcc.dg/guality/example.c -O0 -g -save-temps -lm  
-o ./example.exe

PASS: gcc.dg/guality/example.c  -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to :/gcc-4-5-reg-build/gcc::/gcc-4-5-reg- 
build/gcc

spawn [open ...]
gdb: took too long to attach
WARNING: program timed out.

=

It looks like *when run under dejagnu/expect* the debugger is not  
terminated at the end of the test and (possibly) unavailable for the  
next test.


Is there any doc. (other than what's in the source) on what the  
mechanism is meant to do ..

.. and what we should expect to see...

NOTE: if I build and run the tests indivuidually on the command line  
- they work as expected and the debugger seems to terminate normally.
so it's something to do with the invocation in the dejagnu/expect  
framework.


any help would be most welcome ..
Iain

For reference - these are the patches so far...

Index: gcc/testsuite/gcc.dg/guality/guality.h
===
--- gcc/testsuite/gcc.dg/guality/guality.h  (revision 152226)
+++ gcc/testsuite/gcc.dg/guality/guality.h  (working copy)
@@ -129,12 +129,12 @@

 static const char *guality_gdb_command;
 #define GUALITY_GDB_DEFAULT "gdb"
-#if defined(__unix)
+#if defined(__unix) || defined(__MACH__)
 # define GUALITY_GDB_REDIRECT " > /dev/null 2>&1"
 #elif defined (_WIN32) || defined (MSDOS)
 # define GUALITY_GDB_REDIRECT " > nul"
 #else
-# define GUALITY_GDB_REDRECT ""
+# define GUALITY_GDB_REDIRECT ""
 #endif
 #define GUALITY_GDB_ARGS " -nx -nw --quiet" GUALITY_GDB_REDIRECT

Index: gcc/testsuite/gcc.dg/guality/guality.exp
===
--- gcc/testsuite/gcc.dg/guality/guality.exp(revision 152226)
+++ gcc/testsuite/gcc.dg/guality/guality.exp(working copy)
@@ -3,7 +3,7 @@
 load_lib gcc-dg.exp

 proc check_guality {args} {
-set result [eval check_compile guality_check executable $args "- 
g -O0"]
+set result [eval check_compile guality_check executable $args {"- 
g -O0 -save-temps"} ]

 set lines [lindex $result 0]
 set output [lindex $result 1]
 set ret 0

legitimate parallel make check?

[IainS]

for the sake of keeping information segregated in log files (and  
balancing out test times)

 I tried the following (from within a regression testing script):

'make -k check-gcc-c RUNTESTFLAGS=$runTEST >${STATE}/$svnRevision- 
check-c-log.txt 2>&1' &
(sleep 2) 'make -k check-gcc-c++ RUNTESTFLAGS=$runTEST >${STATE}/ 
$svnRevision-check-c++-log.txt 2>&1' &
(sleep 2) 'make -k check-gcc-fortran RUNTESTFLAGS=$runTEST >${STATE}/ 
$svnRevision-check-fortran-log.txt 2>&1' &
(sleep 2) ' make -k check-gcc-objc RUNTESTFLAGS=$runTEST >${STATE}/ 
$svnRevision-check-objc-log.txt 2>&1' &
(sleep 2) 'make -k check-gcc-obj-c++ RUNTESTFLAGS=$runTEST >${STATE}/ 
$svnRevision-check-obc++-log.txt 2>&1' &
(sleep 2) 'make -k check-target-libstdc++-v3 RUNTESTFLAGS=$runTEST >$ 
{STATE}/$svnRevision-check-target-libstdc++-log.txt 2>&1'&
(sleep 2) 'make -k check-target-libgomp RUNTESTFLAGS=$runTEST >$ 
{STATE}/$svnRevision-check-target-libgomp-log.txt 2>&1' &


firstly; this actually breaks the make process permanently (I suspect  
a race to make site.exp) unless the parallel jobs are launched with a  
time delay.
by permanently I mean that after trying this - "make check-gcc"  fails  
from the command line until config.status is re-run in the gcc dir.




secondly;  if I use  "-k -j3 check-gcc-c "
   together with "-k -j2 check-gcc-fortran " (for example)

I get sporadic bus errors :
/bin/sh: line 1: 67618 Bus error   `if [ -f ${srcdir}/../ 
dejagnu/runtest ] ; then echo ${srcdir}/../dejagnu/runtest ; else echo  
runtest; fi` --tool gfortran --target_board=unix\{-m32,-m64\}  
$runtestflags

make[2]: [check-parallel-gfortran] Error 138 (ignored)

large chunks of tests go silently missing at this point...

===

Am I trying something that is unsupported - or is this is a bug?

===

"make -k -j8 check " is not particularly helpful (a) because it tests  
gmp/mpfr/mpc every time (b) any redirected output is hard to scan for  
problems.


Iain

Re: legitimate parallel make check?

[IainS]

On 9 Mar 2010, at 12:10, Rainer Orth wrote:


IainS  writes:


Am I trying something that is unsupported - or is this is a bug?

===

"make -k -j8 check " is not particularly helpful (a) because it tests
gmp/mpfr/mpc every time (b) any redirected output is hard to scan for
problems.


What you're trying is far too complicated: just use -k -j check  
from
the toplevel and forget about the make check output, which, as you  
say,

is interleaved and useless, just like the make -j bootstrap output.


OK.


Instead, run make mail-report.log afterwards and check that.


Although, I note that contrib/test_summary only reports what gets into  
the *.sum files -- i.e. tests that complete or timeout.
It doesn't log problems in the actual make process itself - to find  
those one still has to trawl through the interleaved stuff.


It would be nice to allow the apparently independent targets [e.g. gcc- 
c,fortran,c++ etc.] to be (explicitly) make-checked in parallel.


thanks,
Iain

Re: legitimate parallel make check?

[IainS]

On 9 Mar 2010, at 12:46, Rainer Orth wrote:


IainS  writes:


Instead, run make mail-report.log afterwards and check that.


... 


suite in parallel, which isn't bad either.


As I wrote before, I'm going to use this on an (effectively) 64-core
machine and hope to achieve to use all cores in parallel :-)


on my mere 8 cores :-)   I'm still getting sporadic Bus errors on:

"make -k -j8 check RUNTESTFLAGS ... "
[from the command line on a bootstrapped clean trunk @157307]

so there's something else wrong somewhere...
... I guess a target-related issue ({i686,powerpc}-apple-darwin9)

(note that this error does *not* get into the .log files, AFAICS)

Iain

Re: legitimate parallel make check?

[IainS]

On 9 Mar 2010, at 19:13, Janis Johnson wrote:

To run all of the compiler tests in parallel you can do "make -jn -k  
check-gcc" from the top level and let the existing build machinery  
take care of running chunks of tests in parallel and putting the  
results back together.


that's fine (I couldn't see why not from looking at Makefile.in)
 (maybe Rainer is right and I have a memory fault on my 8-core  
box .. :-(  ) -- just backing up prior to a single user check of  
that ...


..  I don't seem to get the bus errors on a 4CPU g5 or a Core 2 duo ..  
but .. the 8-core machine is faster .. so ... race conditions are more  
likely to manifest there.



You'd still have to handle the library tests you want to run.


I assume that " make -jn -k check-target RUNTESTFLAGS " is equally  
reasonable?


Perhaps what you want is a way to skip the host library testing,  
although if you're building them with your new compiler then testing  
them is a good part of testing that compiler.


I do build gmp/mpfr/mpc in-tree...
given that I almost always run the whole testsuite - I'm torn between  
thinking it's a good idea..
... and that I'm essentially proving little when the versions of gmp/ 
mpfr/and mpc are static.


--

FWIW: I'm trying to update contrib/btest.sh script to handle m32 & m64  
plus a few other things ...


Iain

Re: legitimate parallel make check?

[IainS]

On 9 Mar 2010, at 19:31, NightStrike wrote:

On Tue, Mar 9, 2010 at 2:27 PM, IainS > wrote:

I do build gmp/mpfr/mpc in-tree...


How?  Last I tried, it didn't work, as mpc used the system gmp/mpfr,
not the just-built in-tree versions.  Therefore, it's not really an
"in-tree" build, and you can't build on a system that doesn't already
have gmp/mpfr installed.  At least, that's what it was... does that
work now?


it's been  fixed for a while (resolution of PR42424)
I keep one copy of gmp mpfr and mpc in a directory at the root of my  
source disk and ln -s to that from within the different gcc source  
trees.


Iain

Re: legitimate parallel make check?

[IainS]

On 9 Mar 2010, at 19:36, Rainer Orth wrote:


IainS  writes:

..  I don't seem to get the bus errors on a 4CPU g5 or a Core 2  
duo .. but
.. the 8-core machine is faster .. so ... race conditions are more   
likely

to manifest there.


But race conditions don't manifest themselves in make SEGVs ;-(  I'm
regularly running make -k -j128 on a T5220, or -j32 on a Sun Fire  
X4450


I'm running memchecks on my 8-core machine ..

Indeed, as well as using a site.exp and pointing the DEJAGNU  
environment

variable at it, as I've learned from looking at the regression tester
sources in contrib/regression.  Here's what I use for that:

global target_list

case "$target_triplet" in {
   { "i?86-*-solaris2.1[0-9]" } {
# FIXME: Disable multilib testing if the host cannot execute AMD64
# binaries.  Should be exceedingly rare now (cf. erebus).
set target_list { "unix{,-m64}" }
   }
   { "mips-sgi-irix6*" } {
# FIXME: Disable multilib testing if the host cannot execute N64
# binaries.  We cannot selectively disable only one multilib during
# the build.
set target_list { "unix{,-mabi=32,-mabi=64}" }
   }
   { "sparc*-*-solaris2*" } {
set target_list { "unix{,-m64}" }
   }
   default {
# Works for alpha*-*-osf*, i?86-*-solaris2.[89] and mips-sgi-irix5*
# testing.
   set target_list { "unix" }
   }
}


that's really neat indeed - I should have spotted the potential  
looking at the code in contrib

...  although the site.exp is hardwired in btest.sh at present ;
 I guess one might be able to use .dejagnurc - just need to check on  
the order that the files are processed.


FWIW: I'm trying to update contrib/btest.sh script to handle m32 &  
m64 plus

a few other things ...


No need: works already via DEJAGNU described above.


hmm.  I see that the make check would work using that neat method  
above...

... however,

1/ I want a different language list than the default...
2/ also some other different configure options...

but mainly
3/
...  As I read it -  btest.sh strips everything but the testname from  
the PASSES and FAILS files. (the awk lines that print $2 for a match  
of /FAIL: / etc.)
This means (e.g.) that if a test passes at m32 and fails at m64 I  
think it will appear in both PASSES and FAILS..

...  this seems destined to result in confusion...

I would like to  identify regressions separately for m32 and m64 -  
esp. in obj-c/c++ where there are huge differences on NeXT runtime  
systems.


if I've missed the blindingly obvious (the day job is taking up most  
of my mental resources ;-)) please point it out :-)


Iain

Re: legitimate parallel make check?

[IainS]

On 10 Mar 2010, at 09:12, Rainer Orth wrote:


IainS  writes:

that's really neat indeed - I should have spotted the potential  
looking at

the code in contrib
...  although the site.exp is hardwired in btest.sh at present ;
I guess one might be able to use .dejagnurc - just need to check on  
the

order that the files are processed.


Far easier: just set the DEJAGNU environment variable to the absolute
path to the size.exp file.  runtest knows about that.

the DEJAGNU env. var is set in btest.sh

hmm.  I see that the make check would work using that neat method  
above...

... however,

1/ I want a different language list than the default...
2/ also some other different configure options...


I've got some local patches for btest-gcc.sh which allow just that
(e.g. support for Ada testing), which I'll submit once I'm reasonably
confident they are general enough.

OK - (but I'm happy that my local mods for this are also working).


but mainly
3/
...  As I read it -  btest.sh strips everything but the testname  
from the
PASSES and FAILS files. (the awk lines that print $2 for a match   
of /FAIL:

/ etc.)
This means (e.g.) that if a test passes at m32 and fails at m64 I  
think it

will appear in both PASSES and FAILS..
...  this seems destined to result in confusion...


You can still use make mail-report.log in the build subdir to get the
complete summary; besides, there's still contrib/dg-cmp-results.sh
(which I haven't checked out yet).


contrib/compare_tests is good (I was thinking to merge the capability  
of that with the capability of btest.sh)

meetings today... so until later

I can't find a hardware fault -- but I'm exploring a hunch about a  
FBKAC 


Iain

Re: legitimate parallel make check?

[IainS]

FWIW;
the bus errors were consistently coming from expect in a strcpy [about  
100 tcl levels down]
the actual fault was a corrupted dejagnu installation - it's not clear  
how that happened - nothing present in syslogs to indicate disk  
problems.

a clean install of dejagnu appears to have cleared the problem.

On 10 Mar 2010, at 09:47, Rainer Orth wrote:


IainS  writes:

I've got some local patches for btest-gcc.sh which allow just that
(e.g. support for Ada testing), which I'll submit once I'm  
reasonably

confident they are general enough.

OK - (but I'm happy that my local mods for this are also working).


Without doubt, but why should everyone trying to use this have to
reinvent the wheel?


indeed, I have every intention of sharing my changes too (at least  
those that are of any merit).


thanks for the help, and apologies that it was noise in the end...
Iain

specs question.

[IainS]

what is the expected behavior of ?

%{.c|.cc|.for|.F90: foo }

.. as I read gcc/gcc.c I would expect to get "foo" for command lines  
with files with these suffixes:

.c
.cc
.for
.F90

but not otherwise (since it says . binds more strongly than |) ;

Iain

post linker phase - How To?

[IainS]

On Darwin we follow the collect2 phase with a call to dsymutil which  
post-processes the object to collect debug info into a separate module.


At present this is done by tricking the driver into calling ld  
followed by dsymutils by appending the dsymutils call onto the end of  
LINK_COMMAND_SPEC.


up to now that's been satisfactory -- but now we might need to change  
things ..


 either:
(a) put a wrapper around the system-provided binary or
(b) provide a replacement.

Of course, I could do this completely outside the gcc scenario .. just  
tell the User "Oh, BTW you need to install XYZ to make this work"...


I'd like to make it easier for them ..

So...
If I want to install a script (wrapper) that will end up installed in  
the same dir as gcc-xyz ...


1/ where do I put that in the GCC source tree?
2/ what do I need to modify in the mechanics to arrange it to get  
installed?


Or:
If I want to create a new post-collect phase --- is that already MACRO- 
ized in gcc or is that a Bigger Job ;-) ??


Iain

Re: specs question.

[IainS]

On 12 Apr 2010, at 23:24, Ian Lance Taylor wrote:


IainS  writes:


what is the expected behavior of ?

%{.c|.cc|.for|.F90: foo }

.. as I read gcc/gcc.c I would expect to get "foo" for command lines
with files with these suffixes:
.c
.cc
.for
.F90

but not otherwise (since it says . binds more strongly than |) ;


That sounds right to me.  Do you see something different


yeah .. we use it in Darwin's dsymutil spec.

%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
   %{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{! 
o:a.out"

%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} }}}\n"


if you put "-lm" on the c/l dsymutil doesn't get called.

Almost as if ".m"  was being treated as a regex rather than a  
suffix... (but I don't think that's the whole story).


and I find that if I put .for|.f90 etc it makes no difference to  
fortran getting debugged...


---
... if I take away the %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: }

It all works as expected...



I looked at the code (briefly) that parses the %{ } but it needs some  
time to digest what's going on - so I thought asking would be a good  
plan ;-)


Iain

Re: post linker phase - How To?

[IainS]

On 12 Apr 2010, at 23:30, Ian Lance Taylor wrote:


IainS  writes:


If I want to install a script (wrapper) that will end up installed in
the same dir as



.  If this program will only ever be
run by the gcc driver, then you should install it in either the
directory where cc1 is installed, $(libsubdir),


This is the right place, at least for a wrapper...

If we make a stand-alone replacement (one day) then maybe that could  
be put in $(bindir)


I take it that, when called from a spec, any program in $(libsubdir)  
will get the right path by the automagic built into the compiler?



Or:
If I want to create a new post-collect phase --- is that already

As far as I know there is currently no post-collect phase.


This would be tidier than riding on the back of the LINK_COMMAND_SPEC.
Any perception of the difficulty factor (1:10)..?

Iain

Re: specs question.

[IainS]

On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:


IainS  writes:


yeah .. we use it in Darwin's dsymutil spec.

%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
   %{.c|.cc|.C|.cpp|.cp|.c++|.cxx|.CPP|.m|.mm: \
  %{gdwarf-2:%{!gstabs*:%{!g0: dsymutil %{o*:%*}%{!
o:a.out"
   %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} }}}\n"


if you put "-lm" on the c/l dsymutil doesn't get called.


Note that in the specs language the %{.XXX: ...} is matched against
the filename passed to the gcc driver.  It doesn't know the source
language of a .o file.  So if you are linking, and passing .o files,
then this approach won't work.


well, my first question to myself was 'why are there not ".o" and ".a"  
in the list?'  ;))


There are two aspects to this ...
1/ the fact that this is probably not the right thing to do in that  
spec - easily solved by deleting it..


2/ The weird effect where putting -lm on the c/l causes the  
substitution to fail - which hints at a deeper problem.
FWIW I couldn't (quickly) find any other spec using that syntax - so  
perhaps it's not important.


cheers,
Iain

Re: specs question.

[IainS]

On 13 Apr 2010, at 00:22, Ian Lance Taylor wrote:

if you put "-lm" on the c/l dsymutil doesn't get called.


Note that in the specs language the %{.XXX: ...} is matched against
the filename passed to the gcc driver.  It doesn't know the source
language of a .o file.  So if you are linking, and passing .o files,
then this approach won't work.


(I saw your post about java .. I wasn't grepping the right things .. )

Since we're tagged onto the LINK_COMMAND_SPEC - this will get  
evaluated whenever that does.
... (not 100% sure when that is - when the driver is invoked or when  
the collect phase is invoked.. ).
.. also in_files and out_files can exhibit gotchas (e.g. anything  
beginning -l isn't eligible for treatments like %

---

It clearly depends on something no-obvious.

gcc hello.c  -g -o hc  => dsymutils gets run  (not expected from the  
syntax, assuming that sources are irrelevant)


gcc hello.o -g -o hc  => no dsymutils (expected from the absence of  
'.o' in the list)


gcc hello.c -g -o hc -lm => no dsymutils... (not at all expected ... )

adding .for to the list does not result in dsymutils getting run ..   
(expected by similarity, but not by logic)


removing the whole of the bracketed list -  results in all of those  
cases working.


I think the right local solution is to remove the expression (I'll run  
that by Mike Stump)...


I'm pursuing this in case there's a latent bug that should be reported.
cheers,
Iain

Re: specs question.

[IainS]

On 13 Apr 2010, at 19:05, Peter O'Gorman wrote:


gcc hello.c  -g -o hc  => dsymutils gets run  (not expected from the
syntax, assuming that sources are irrelevant)

gcc hello.o -g -o hc  => no dsymutils (expected from the absence of  
'.o'

in the list)



We don't want to run dsymutil if there are .o files, let the developer
do that.


OK, although AFAICT,
 it should be harmless doing it in the general case (and, to some  
extent, more friendly).


If someone just does gcc -g -o foo foo.c, then any debugging  
information

will be lost when the temporary .o file is removed, thus, to allow
debugging such a foo, the compiler must run dsymutil.


That's understood - although see below for a comment on Fortran***.


Strange, Apple's gcc-4.2 doesn't have this bug (-lm), yet that portion
of the specs appears identical.


indeed - although of course there's no reason to suppose that gcc/ 
gcc.c is identical in the two cases (I can check that at some stage)


My question has more to do with whether the apparent intention of the  
spec is being honored..
... and also why it doesn't work if I add more extensions (e.g. to  
extend coverage to Fortran, which Apple are not trying to cover in  
their case).


[***Even if I remove the %{.xxx.xxx.xx: } in the dsyutil section,  
there's a subsidiary issue with the Fortran case in that the debug  
info is only working if I put -save-temps on the CL].


cheers,
Iain

On the use of abort() in the testsuite

[IainS]

I feel in my bones that this will probably have been discussed  
before ... but.


On my platform of choice when abort() is called it tries to

a) generate a coredump
b) formats and saves a cute crashdump to allow non-expert users to  
forward failure info to application writers or the system vendor.


This is quite consuming of system resources when running the gcc  
testsuite which is full of abort() calls.


I queried darwin-dev about switching off (b)
 [although one is normally reluctant to do so - because it's actually  
pretty useful]

however, this is non-trivial and not an option on a a day-today basis.

Also the response to (a) was that doing a coredump is a POSIX- 
compliant response to abort().


(I obviously set ulimit to 0 for cores to work around this).



So... I wonder what does abort() offer to the testsuite?

 that, for example,   _exit(-(__LINE__)) ;

doesn't?

These days, running the testsuite way outweighs (> 2:1)  building the  
compiler - so any possible ways to improve turn-round time on regtests  
would be cool.


(of course, it's a lot of editing to do just to find out.. )

Iain

Re: On the use of abort() in the testsuite

[IainS]

On 14 Apr 2010, at 21:42, Ian Lance Taylor wrote:


IainS  writes:


So... I wonder what does abort() offer to the testsuite?

that, for example,   _exit(-(__LINE__)) ;

doesn't?


The testsuite can be run on embedded systems over serial ports, where
is sometimes limited communication available.


ah, indeed .. I remember such when 8-bits/500kHz bus was state-of-the- 
art ;)


One wonders if things are quite so grim these days though.


Using two functions is flexible in a different way: it means that you
can compile the testsuite with -Dabort=my_favorite_abort and link
against your own library.  So do that.  You can do this with magic in
site.exp, but don't ask me what that magic is because I no longer
remember.


I'll have to figure that out and report back.

Thanks for the info,
Iain

finding an original typedef decl from a reference

[IainS]

consider :

typedef int INT1 ;

int func (INT1 x) ;



now if I am in grokparms()  parsing "INT1 x " and I want to issue a  
nice diagnostic for x...


I can't seem to find the right magic that gets me back to that DECL  
for INT1

(I actually want any attributes attached to it and an expand_location)..

any pointers to the correct macro or chain to follow...?

Iain

Re: finding an original typedef decl from a reference

[IainS]

On 19 Apr 2010, at 14:18, Manuel López-Ibáñez wrote:

On 19 April 2010 15:03, IainS   
wrote:


consider :

typedef int INT1 ;

int func (INT1 x) ;



now if I am in grokparms()  parsing "INT1 x " and I want to issue a  
nice

diagnostic for x...


Can I ask what you mean by a nice diagnostic? and what you want to  
use this for?


nice ; including the expand_loc for INT1 and any attributes attached  
to the decl.


use ; I'm working on __attribute__((deprecated)) issues ...

(at the moment the diagnostic for x does not include the declaration  
location).


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43778 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43797
and the earlier thread on patches.
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01037.html
and a followup:
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01092.html

All this as a prelude to trying to introduce  
__attribute__((unavailable)) which is needed to progress ObjC to  
Version 1.


Iain

__Unwind_GetIPInfo on Darwin 8.11

[IainS]

hi,

a freshly-checked-out gcc trunk, bootstraps fine and check is OK on gcc.
However, I'm finding a huge number of failures with g++ caused by the  
fact that  __Unwind_GetIPInfo is not defined.


When 'make checking', I conventionally move the built libgcc_s. 
1.dylib and libgcc_s.10.4.dylib to one side prior to testing (so that  
the Apple-supplied system version is used).


__Unwind_GetIPInfo is not present in the stock:
 /usr/lib/libgcc_s.1.dylib or /Developer/SDKs/MacOSX10.4u.sdk/usr/ 
lib/libgcc_s.1.dylib


[the symbol IS present in libgcc_s.1.dylib built from trunk]

---
Is this the expected behavior?  (there doesn't appear to be an update  
to the library version).


If so - I guess that anyone building with 4.4 would have to supply an  
updated libgcc ???


cheers,
Iain

Re: __Unwind_GetIPInfo on Darwin 8.11

[IainS]

Hello Jack,
On 21 Nov 2008, at 18:35, Jack Howarth wrote:


On Fri, Nov 21, 2008 at 03:57:15PM +, IainS wrote:
When 'make checking', I conventionally move the built libgcc_s. 
1.dylib

and libgcc_s.10.4.dylib to one side prior to testing (so that the
Apple-supplied system version is used).

__Unwind_GetIPInfo is not present in the stock:




Since the libgcc can contain new symbols which older libgcc's  
may not
and libstdc++ is built against this newer libgcc, I wouldn't expect  
it to

necessarily work.


OK.

I would note that the recommended approach for building llvm-gcc42  
is for the FSF gcc's libstdc++-v3 to be removed from the source

tree so that the system copy is used. I wouldn't be surprised if the


Whilst this is true of the Apple open source distribution, I don't  
think it's what the regression tester at

http://gcc.gnu.org/regtest/HEAD/
is doing since there seem to be test results produced for libstdc++ etc.

I tried the removal step, just to make sure - and it caused a whole  
different set of FAILs


---

Do you have (or know where to find) the scripts that are used by  
"regress" ?  -- I still can't 100% replicate the results on 8.11 with  
the exact command line options from the regress test_summary log  file.


---

Other than the comment above, I think that the main source of  
differences I see are to do with using " --enable-version-specific- 
runtime-libs " and then running make check without installing the  
compiler to its final position (there are differences in the embedded  
rpaths in libstdc++, and libgfortran, gomp etc).   I haven't got to  
the bottom of this yet.. it all takes time, which is ever in short  
supply.


cheers,
Iain

Re: __Unwind_GetIPInfo on Darwin 8.11

[IainS]

On 27 Nov 2008, at 01:13, Geoff Keating wrote:



On 26/11/2008, at 4:16 PM, Jack Howarth wrote:


On Wed, Nov 26, 2008 at 01:22:35PM -0800, Geoffrey Keating wrote:

Jack Howarth <[EMAIL PROTECTED]> writes:


Iain,
  The use of the system libgcc simply won't work on Mac OS X 10.4.
The missing __Unwind_GetIPInfo only exists in libgcc_s.10.5.dylib
and not libgcc_s.10.4.dylib...


Replacing or modifying the system libgcc is not recommended and may
break in the next version of Mac OS X.  It's not clear to me what  
this

will mean for GCC development.

You can see the exact commands the regression tester used in the  
build

log file at
;  
basically,


+ /Users/regress/tbox/svn-gcc/configure --prefix=/Users/regress/ 
tbox/objs --target=powerpc-apple-darwin8.5.0

+ make -j2 bootstrap
+ make -j2 -k check

No extra flags, no moving stuff around, nothing added or deleted  
from

the GCC source tree; that would defeat the purpose of the regression
tester, which is to test the actual GCC in the repository.  There is
some strangeness in the system configuration: GMP and MPFR are
installed in /usr/local as static libraries, and I seem to
remember the system is running with a modified kernel, containing a
patch which makes dejagnu work, which is why it's running 10.4.5.

10.4.11 is significantly different from 10.4.5 and from 10.5.  I
believe it adds a shared libgcc and libstdc++.  It may be that GCC
does not work on 10.4.11.

You can find the exact scripts the tester uses to run the build in
contrib/regression in the GCC source tree.  The tester checks out  
the

tree and runs the scripts from the checkout.


Geoff,
  I think you misunderstood my intention with that statement. I  
wasn't
suggesting that Iain move a libgcc.so.10.5.dylib onto a different  
machine.
Rather I meant that the offending symbol, __Unwind_GetIPInfo, was  
only added
to the system libgcc for 10.5 so that Tiger's system libgcc would  
never

be able to provide it.


I should correct an earlier statement of mine: 10.4.11 does not add  
a shared libgcc.  My 10.4.5 machine has a shared libgcc which  
indeed does not have __Unwind_GetIPInfo.  However, this does not  
prevent GCC building on it.



Geoff,

Thanks for pointing to the scripts; I'll examine them in more detail.

There was never  a problem *building* gcc, nor is there apparently  
any problem once installed to the correct place.
[ i.e. Once the compiler is installed (and it is used to generate  
code from its installed position) everything is apparently OK.]


The problem was failures in "make check" (esp. with an uninstalled,  
newly built, compiler)
the failures were caused by the fact that the newly-built libgcc was  
not being found - and the symbol(s) are not present in /usr/lib/libgcc*


In fact, as far as g++ and libstdc++ tests are concerned, this was  
apparently a temporary glitch and the test results are looking the  
same as "regress" now.


===

However, I still find similar a problem with libgomp (see http:// 
gcc.gnu.org/ml/fortran/2008-11/msg00320.html )


This is repeatable on several machines...

.. so there is something I've got installed, or something I'm doing  
differently (or wrong) and I'd like to get to the bottom of it.  This  
is a very time-consuming activity - it would be a shame to waste the  
processor cycles and man-hours.


As far as the OS is concerned - I take care not to interfere with it;  
any added stuff is in /opt,  /sw, /xusr and very occasionally /usr/ 
local.
These are, however, in-use live systems with 3rd party apps and  
drivers - so it's not impossible that something has been horked by  
one of those.


FWIW I am using dejagnu-1-4-4 which seems to build and install  
without any change or addition to OSX.


the PATH I use (on darwin8) for the configure/build/check is:
"/usr/local/dejagnu-1-4-4/bin:/bin:/sbin:/usr/bin:/usr/sbin"

I'm building GMP (4.2.4) and MPFR(2.3.2) in the gcc tree - but that  
makes no material difference to the observation AFAICT.


thanks,
Iain

should make check be done "un-installed"?

[IainS]

Hello all,

The implication of the opening statement of  http://gcc.gnu.org/ 
install/test.html is that "make check" could (or even should) be done  
before "make install"


Is this a correct interpretation of policy?

tia,
Iain

TLS on darwin

[IainS]

Hi,

following on from http://gcc.gnu.org/ml/gcc/2008-05/msg00202.html

should I expect

"--enable-tls"

to produce a functional result on {intel,powerpc}-*-darwin{8,9}

or should all testcases with thread local requirements be wrapped with

{ dg-require-effective-target tls_runtime }

thanks,
Iain

Re: TLS on darwin

[IainS]

On 8 Dec 2008, at 21:09, Andrew Pinski wrote:

On Mon, Dec 8, 2008 at 1:04 PM, IainS <[EMAIL PROTECTED] 
acoustics.co.uk> wrote:

following on from http://gcc.gnu.org/ml/gcc/2008-05/msg00202.html


As I mentioned; it is emulated.  So it works, by default, though it is


hm.  At the moment it doesn't appear to work.

with configure options   "--enable-threads"(or default options)  
we get the situation described below.
with configure options   "--enable-threads --enable-tls" we get an  
assembler fault instead.


= with "--enable-threads" (and also default options).

(see also PR32765 and http://gcc.gnu.org/ml/fortran/2008-12/ 
msg00118.html)


___emutls_get_address is defined in libgcc_s.1.dylib (and libgcc_eh.a)

As you suggest in the PR32765 thread, the problem is that libgcc_s.1  
is not searched unless this is forced on the options line.


However, the problem is much wider than those two tests.

check_effective_target_tls_runtime in target-supports.exp also fails  
with the same error - this "UNSUPPORTS" pretty much all TLS tests  
across gcc on darwin8/9.


The only reason that the PR32765 issue was visible is that the two  
test cases do not use { dg-require-effective-target tls_runtime }




The workaround used to close PR32765 no longer functions on darwin8  
(unless the the compiler is installed before checking) - although it  
does still work on darwin9.


The  ___emutls_get_address in libgcc_s.1 also appears to have some  
issues on 64bit processors, both PPC and Intel (at least when running  
32 bit code).


The version in libgcc_eh does work (which is why the --static-libgcc  
approach is succeeding on darwin9).


so a more closely targeted workaround is to use -lgcc_eh in any  
darwin code that requires TLS (this works on darwin8 and darwin9).


However, this seems like a pretty messy solution - and prone to all  
sorts of symbol conflicts when more than ___emutls_get_address is  
involved.


=

I'm afraid I'm out of my depth here gcc has quite a learning  
curve...


... is the problem one of SPECs ?
.. or does every single TLS case need a darwin-specific addition to  
reference -lgcc_eh ?
.. I guess also that target-supports.exp would need some modification  
to account for this...


cheers,
Iain

Re: TLS on darwin

[IainS]

A little additional info:

PPC darwin8 (if configured --enable-tls --enable-threads) fails the  
check_effective_target_{tls, tls_runtime, tls_native} with a compiler  
ICE

viz, for example:
tls_native7888.c:3: internal compiler error: in  
rs6000_legitimize_tls_address, at config/rs6000/rs6000.c:4080


if configured (--enable-threads, or default) it behaves as described  
previously.


On 9 Dec 2008, at 19:14, Richard Henderson wrote:


... is the problem one of SPECs ?


I don't think so, unless we can key off -pthread or something.


one could conceive of making the TLS emulation specific with, say "- 
femulate-tls" (for those platforms that require it).


.. or does every single TLS case need a darwin-specific addition  
to reference -lgcc_eh ?

We can add that via tls.exp.


This needs to be included from places like libgomp - and possibly  
others.


I guess I'm also concerned about how one communicates this "need" to  
end-users.


Presumably, one should ideally use the version in libgcc_s.1?

There are also a whole other bunch of things in libgcc_eh (or  
libgcc_s.1) which, ultimately, leads to a worry about different parts  
of the same code ending up linked against different versions of the lib.


.. I guess also that target-supports.exp would need some  
modification to account for this...


Yes, that would require changes.


OK, thanks,
Iain

[PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS]

Hi all,

ref:  http://gcc.gnu.org/ml/gcc/2008-12/msg00107.html, PR32765 and  
http://gcc.gnu.org/ml/fortran/2008-12/ msg00118.html


NOTE to gurus:  the whole libgcc_eh, libgcc_s.{10.x, 1} thing is  
quite hard to understand.
I searched gcc.pdf, gccint.pdf  (0 hits) and the list (not much) ...  
and google (mostly speculation).


In the end I had to RTSC

If I now understand correctly, the symbols present in updated  
versions of libgcc that are not in the "stock" system libgcc on  
darwin - need to be mentioned in the stub libraries (ligcc_s.10. 
{4,5,...} ).  The emutls ones were not present causing linkage  
failures that were silently UNSUPPORTING a lot of tests.


It's also possible that key tests might fail on 64bit processors (see  
the referenced threads) which could also result in "UNSUPPORTS"  
appearing and disappearing sporadically.


"bootstrap-lean" and "make check"  on powerpc-apple-darwin8 and i386- 
apple-darwin9 (both on 64 bit processors).


this results in:
g+++1  supported
gcc+4  supported
libgomp+126 supported

I'll look at 32bit processor builds during today.

do you think this is the proper solution ?

Iain

===

Index: gcc/config/i386/darwin-libgcc.10.5.ver
===
--- gcc/config/i386/darwin-libgcc.10.5.ver  (revision 142592)
+++ gcc/config/i386/darwin-libgcc.10.5.ver  (working copy)
@@ -83,3 +83,5 @@
 ___udivdi3
 ___udivmoddi4
 ___umoddi3
+___emutls_get_address
+___emutls_register_common
Index: gcc/config/i386/darwin-libgcc.10.4.ver
===
--- gcc/config/i386/darwin-libgcc.10.4.ver  (revision 142592)
+++ gcc/config/i386/darwin-libgcc.10.4.ver  (working copy)
@@ -79,3 +79,5 @@
 ___udivdi3
 ___udivmoddi4
 ___umoddi3
+___emutls_get_address
+___emutls_register_common
Index: gcc/config/rs6000/darwin-libgcc.10.5.ver
===
--- gcc/config/rs6000/darwin-libgcc.10.5.ver(revision 142592)
+++ gcc/config/rs6000/darwin-libgcc.10.5.ver(working copy)
@@ -87,3 +87,6 @@
 ___udivdi3
 ___udivmoddi4
 ___umoddi3
+___emutls_get_address
+___emutls_register_common
+
Index: gcc/config/rs6000/darwin-libgcc.10.4.ver
===
--- gcc/config/rs6000/darwin-libgcc.10.4.ver(revision 142592)
+++ gcc/config/rs6000/darwin-libgcc.10.4.ver(working copy)
@@ -74,3 +74,5 @@
 ___udivdi3
 ___udivmoddi4
 ___umoddi3
+___emutls_get_address
+___emutls_register_common

Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS]

On 10 Dec 2008, at 14:43, Jack Howarth wrote:


shipped by Apple with its OS releases. I think what you want to do
make sure you are using the FSF libgcc's and not the system ones
while having environmental MACOSX_DEPLOYMENT_TARGET unset. The latter
step will cause the unversioned libgcc to be used with all the newer
symbols specific to the FSF gcc 4.4 release (that are not listed in
the darwin-libgcc.10.4.ver and darwin-libgcc.10.5.ver files).


I have not found a way (MACOSX_DEPLOYMENT_TARGET set or unset) of  
getting the loader to look at the FSF libgcc_s.1.dylib unless I  
specifically name it on the command line with -lgcc_s.1


That does work ( as does -lgcc_eh. )

I guess I misunderstood the purpose of libgcc_s10.x as being "all the  
symbols added since this release"


It would help if someone could point me at some clear documentation  
about what


libgcc_eh
libgcc_s.1
libgcc_s.10.X

*should* contain.

other than that, it's a case of returning to some solution which  
involves a tls.exp... etc.


thanks,
Iain

Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS]

On 10 Dec 2008, at 18:10, Mike Stump wrote:


On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:
If I now understand correctly, the symbols present in updated  
versions of
libgcc that are not in the "stock" system libgcc on darwin - need  
to be
mentioned in the stub libraries (ligcc_s.10.{4,5,...} ).  The  
emutls ones
were not present causing linkage failures that were silently  
UNSUPPORTING

a lot of tests.


No, those files are meant to describe what was shipped in the past  
on darwin as part of darwin.  So, changing them isn't quite the  
right way to do this.  Best to put them in the libgcc.a file and  
let them link in statically.  Is there some reason why this doesn't  
work?  I can answer questions and offer advice, feel free to cc me.


thanks MIke,

the basic issue is that TLS (as used extensively within gomp) is  
implemented, at present, as an emulation (emutls).


This is present in libgcc_s.1.dylib and libgcc_eh.a

However, as Jack says, it seems currently very difficult to persuade  
gcc to extract symbols from this un-versioned lib (without mentioning  
it specifically on the CL)


Whilst this is a possible work-around for getting the test suite to  
work, it concerns me that it's quite obscure and prone to being  
missed out, forgotten, and/or fragile.


There is an added inconvenience in that darwin8's ld command behaves  
differently from darwin9's


the only work-around I've found that gives equal results on d8 and d9  
is to specify -lgcc_eh


these approaches seem like temporary hacks .. and I wonder what a  
good long-term solution would be?


cheers,
Iain

Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS]

On 10 Dec 2008, at 19:05, Jack Howarth wrote:


On Wed, Dec 10, 2008 at 06:23:18PM +, IainS wrote:


On 10 Dec 2008, at 18:10, Mike Stump wrote:


On Dec 10, 2008, at 9:43 AM, Jack Howarth wrote:

If I now understand correctly, the symbols present in updated
versions of
libgcc that are not in the "stock" system libgcc on darwin - need
to be
mentioned in the stub libraries (ligcc_s.10.{4,5,...} ).  The
emutls ones
were not present causing linkage failures that were silently
UNSUPPORTING
a lot of tests.


No, those files are meant to describe what was shipped in the  
past on
darwin as part of darwin.  So, changing them isn't quite the  
right way
to do this.  Best to put them in the libgcc.a file and let them  
link in
statically.  Is there some reason why this doesn't work?  I can  
answer

questions and offer advice, feel free to cc me.


thanks MIke,

the basic issue is that TLS (as used extensively within gomp) is
implemented, at present, as an emulation (emutls).

This is present in libgcc_s.1.dylib and libgcc_eh.a

However, as Jack says, it seems currently very difficult to  
persuade gcc

to extract symbols from this un-versioned lib (without mentioning it
specifically on the CL)

Whilst this is a possible work-around for getting the test suite to
work, it concerns me that it's quite obscure and prone to being  
missed

out, forgotten, and/or fragile.

There is an added inconvenience in that darwin8's ld command behaves
differently from darwin9's

the only work-around I've found that gives equal results on d8 and  
d9 is

to specify -lgcc_eh

these approaches seem like temporary hacks .. and I wonder what a  
good

long-term solution would be?

cheers,
Iain


Iain,
   I know we have...

if [istarget *-*-darwin*] {
lappend ALWAYS_CFLAGS "additional_flags=-shared-libgcc"
}

in libgomp/testsuite/lib/libgomp.exp. So you have to make sure
that gets overridden if you wan to use --static-libgcc.
This change was discussed here...

http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01497.html

  Jack


Yes, that's understood.  However:

--static-libgcc does not work (any more, if it used to) with D8  
(unless you install the compiler before make check).


libgomp.1.dylib => libgcc_s.1.dylib and D8's ld command objects.

I already commented that if you do --static-libgcc with D9 then

libgomp -> libgcc_s.1
mainline -> statically linked with libgcc.a

this doesn't seem a good idea.

using libgcc_eh.a minimises this (in the case of the libgomp tests)  
because the only symbols that happen to be sourced are the __emutls  
ones.


However, that's not a general case.

=-

I suppose I'd expected the current *compiler* symbols to take  
precedence over the system ones (unless I specifically demand that  
the linked binary is usable w/out delivering the updated runtimes).


For any of this to be useful to an end-user we must accept that the  
libgfortran/libgomp .. etc etc. runtimes would have to be installed  
on the end-user's system (since they are not currently part of any D8/ 
D9 system).


`pologies, if I'm being slow... there is a large learning curve here...

cheers,
Iain

Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS]

On 10 Dec 2008, at 19:46, Jack Howarth wrote:



Since your objections are entirely related to the testsuite when
FSF has not been installed,


hm. I'm not entirely sure that's the whole case... although that was  
the trigger for this chain of investigation.


 I'm also wondering what instructions one gives to the developer  
about how code using TLS should be built/delivered.



perhaps it would be more productive to see
if the testsuite in libgomp can be reworked to handle darwin when
gcc is uninstalled.


the patch below gives the same result on D9 (checking is still  
running on D8) as the change I posted earlier (for libgomp only)
obviously a similar thing needs to be done other places where TLS is  
used.


Index: libgomp/testsuite/lib/libgomp.exp
===
--- libgomp/testsuite/lib/libgomp.exp   (revision 142648)
+++ libgomp/testsuite/lib/libgomp.exp   (working copy)
@@ -113,9 +113,15 @@
if { "$mldir" == "." } {
  continue
}
-	if { [llength [glob -nocomplain ${gccdir}/${mldir}/ 
libgcc_s*.so.*]] >= 1 } {

- append always_ld_library_path ":${gccdir}/${mldir}"
-   }
+   if [istarget *-*-darwin*] {
+			if { [llength [glob -nocomplain ${gccdir}/${mldir}/ 
libgcc_s*.dylib]] >= 1 } {

+   append always_ld_library_path 
":${gccdir}/${mldir}"
+   }
+   } else {
+			if { [llength [glob -nocomplain ${gccdir}/${mldir}/ 
libgcc_s*.so.*]] >= 1 } {

+   append always_ld_library_path 
":${gccdir}/${mldir}"
+   }
+   }
  }
}
 }
@@ -127,7 +133,6 @@
 lappend ALWAYS_CFLAGS "ldflags=-L${blddir}/.libs"
 }
 lappend ALWAYS_CFLAGS "additional_flags=-I${srcdir}/.."
-lappend ALWAYS_CFLAGS "ldflags=-lgomp"

 # We use atomic operations in the testcases to validate results.
 if { ([istarget i?86-*-*] || [istarget x86_64-*-*])
@@ -135,10 +140,6 @@
lappend ALWAYS_CFLAGS "additional_flags=-march=i486"
 }

-if [istarget *-*-darwin*] {
-   lappend ALWAYS_CFLAGS "additional_flags=-shared-libgcc"
-}
-
 if [istarget sparc*-*-*] {
lappend ALWAYS_CFLAGS "additional_flags=-mcpu=v9"
 }
@@ -153,6 +154,15 @@

 # And, gee, turn on OpenMP.
 lappend ALWAYS_CFLAGS "additional_flags=-fopenmp"
+   
+if [istarget *-*-darwin*] {
+ #lappend ALWAYS_CFLAGS "additional_flags=-shared-libgcc"
+ # we need to use the unversioned libgcc to pick up the TLS emulation
+  lappend ALWAYS_CFLAGS "additional_flags=-lgcc_s.1"
+} else {
+ # it's not clear who needs this ... -fopenmp should do this no?
+  lappend ALWAYS_CFLAGS "ldflags=-lgomp"
+   }
 }

 #

Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS]

On 10 Dec 2008, at 19:58, Mike Stump wrote:


emulation package, which has nothing to do with eh, right?)


that thought had crossed my mind a few times  ;-)

can be found.  Another possibility, would be to split out the tls  
emulation package from gcc_eh.  We avoid gcc_eh, so as to not pull  
in any routines that would shear with those in the system libgcc_s.


I wondered about making all this specific with a "-femulate-tls" and  
the associated SPEC.


However, I'm way out of my depth here - in terms of appreciating the  
implications of such a thought.


Iain

Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS]

Thanks Geoff,
that's v. useful doc.

On 10 Dec 2008, at 22:36, Geoff Keating wrote:



On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:


On Wed, Dec 10, 2008 at 02:55:11PM +0000, IainS wrote:




To use the 'unversioned set' implies that you're compiling for a  
version of Mac OS that Apple has not yet created and most likely  
will never exist.  This is not useful.


One way to get extra runtime support is put routines in libgcc.a  
which can be statically linked into executables if they aren't  
present in the system.



if one did -lgcc_s.10.x -lgcc_s.1   would that break it?
... should it not pick up only the unresolved symbols from s.1

( you would also have to be  prepared to install libgcc_s.1 in a  
suitable place).




The routines in libgcc_eh.a are routines which should normally  
never be statically linked into executables, because they won't  
work if you do that; they must be in the system.  If you need a  
routine that's in libgcc_eh.a, and it's not in the system, you're  
out of luck; you can't use it.  You'd need to rewrite it so it can  
handle being linked into multiple executables, or you'd need to  
create a new shared library, put the routine in it, and ship that  
shared library with every executable you create.


OK, we've got quite a bit of work to do then, all the runtime libs  
(gfortran, stdc++v3, gomp, ffi, java)  link on libgcc_s.1.dylib


and, if we want to be able to use gomp, then I we need to find a way  
to provide emutls.


This, obviously, should not be by linking with gcc_eh (since people  
would want the current system-provided exception mechanism to  
continue to work, I imagine).


thanks, for the explanations - it's been an educational day!

Iain

Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS]

Gents,
thanks for taking the time to explain stuff - hopefully, in the end,  
we'll resolve this.


---

Firstly, issues with my choice of configure options might be  
important - but they are not relevant to the underlying problem.
	The basic problem is entirely repeatable with default options  
("regress", for example, shows 128 unsupported libgomp tests).


I am happy to be 'blown out of the water' here - but I do want to  
understand the limitations.


If gcc X.Y can deliver greater functionality than the default install  
on darwinX then, IMO, I should be able to pass this onto my clients  
and users.
Obviously, I want to do this in a secure manner, that does not break  
the system for my clients, and is understandable by developers.
[* I am not trying to replicate your work Jack, but seeking a  
different deployment solution - which is required in some cases].


We have strayed, to some extent, from the specific issue of TLS into  
more general areas;  but these are v. important areas (and one might  
at least see this list as partial documentation for some future  
engineer also trying to understand).


===

apropos  emutls (I emailed Jakub, who kindly replied)

1/ The reason that emutls is in gcc_eh is because there must be only  
one copy in an executable.


So, in the general case, when using emults, one must:
(a) link all parts of the executable using emutls statically  (which  
is tedious to achieve on darwin without moving all the dylibs to one  
side)

(b) link with the libgcc_s.1that contains emutls.

so, AFAICT (at least on darwin) these are broken w.r.t emutls:
	gcc main-progam.c -lgcc_eh -lsome-library-already-linked-to-emutls- 
in-gcc_s.1 .
	gcc main-progam.c -lstatic-libgcc -lsome-library-already-linked-to- 
emutls-in-gcc_s.1 .
	(in fact, D8 ld won't let you do the second unless "some-library- 
already-linked-to-emutls-in-gcc_s.1" is already installed).


I have a hunch that this is, at least partially, the origin of  
sporadic failures in crayptr2 (which has been one of the very few  
tests using tls so far - because all the rest have been UNSUPPORTED  
by the fails in dg target supports).


2/  If I understand correctly, one must link with the ex. handlers in  
libSystem if one wants proper operation languages using exceptions  
(i.e. the reason that --shared-libgcc is used in the testsuite).  **  
see also below.


So, my kludge to libgomp.exp  "-lgcc_s.1" is probably broken with  
respect to ex. handlers for g++, objc etc.


- unless it's acceptable for a single executable to get its EH code  
from a newer libgcc_s.1
(i.e. is it a matter of consistency, or *must* the EH code absolutely  
come from libSystem, for some other reason ?)


If the static libs are segregated because of these needs - then why  
not segregate the dylibs?
I.E. put the EH code in libgcc_eh.so (which can then be ignored on  
darwin)



apropos the general issue of supplying an enhanced gcc runtime set  
onto darwinX

(assuming that the problems are fundamentally resolvable).

On 11 Dec 2008, at 00:13, Geoff Keating wrote:

On Dec 10, 2008, at 3:24 PM, IainS wrote:

On 10 Dec 2008, at 22:36, Geoff Keating wrote:

On Dec 10, 2008, at 7:32 AM, Jack Howarth wrote:

On Wed, Dec 10, 2008 at 02:55:11PM +, IainS wrote:




To use the 'unversioned set' implies that you're compiling for a  
version of Mac OS that Apple has not yet created and most likely  
will never exist.  This is not useful.


One way to get extra runtime support is put routines in libgcc.a  
which can be statically linked into executables if they aren't  
present in the system.


if one did -lgcc_s.10.x -lgcc_s.1   would that break it?
... should it not pick up only the unresolved symbols from s.1

( you would also have to be  prepared to install libgcc_s.1 in a  
suitable place).


The second part here is the tricky part.  I would not recommend  
installing your libgcc_s.1.dylib in /usr/lib, or anywhere else  
really, since you don't know that it'll be compatible with the  
system one.


(a)
--enable-version-specific-runtime-libs**
should ensure that this is achieved without any risk of trampling on  
the system (we certainly do not want to take responsibility for that).
(and with --program-suffix=-x.y.z allows me to have 4.3 and 4.4  
installed along with apple-released 4.0 and 4.2 ... )

 ** providing one does *not* use --with-slibdir=/usr/lib (see below)

(b)
an alternative (especially attractive to me) is:

package a set of gccx.y libs with rpaths @executable_path/../lib

I can then deliver this as a user drag-installable app (perhaps  
wasteful of disk space, but nicely self-contained) :


MyAppUsingGFortran.app
Contents/
MacOS/
MyAppUsingGFortran
lib/
libgfortran.dylib
etc.
libgcc_s.1.dylib

(c) There are

Re: [PATCH, DARWIN] fix emutls exports in libgcc_s10.{4,5}.dylib

[IainS]

On 11 Dec 2008, at 13:51, Jack Howarth wrote:


On Thu, Dec 11, 2008 at 12:38:11PM +, IainS wrote:
...


I have a hunch that this is, at least partially, the origin of  
sporadic
failures in crayptr2 (which has been one of the very few tests  
using tls
so far - because all the rest have been UNSUPPORTED by the fails  
in dg

target supports).

...

No. The random failures in crayptr2 are due to multiple threads  
reading

an offset value of 0 and is fixed by the proposed patch...

http://gcc.gnu.org/bugzilla/attachment.cgi?id=16879


actually, the deeper one digs ...

it seems that libgomp is not being built with tls emulation.

(for exactly the same reasons - the configure test fails with the  
unresolved __emutls...  symbol)


from libgomp/config.h
/* Define to 1 if the target assembler supports thread-local storage. */
/* #undef HAVE_CC_TLS */



/* Define to 1 if the target supports thread-local storage. */
/* #undef HAVE_TLS */

and libgomp/config.log

tchCS/gcc-440-install/powerpc-apple-darwin8.11.0/sys-include -o  
conftest -g -O2   -pthread   conftest.c  >&5

/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
___emutls_get_address
collect2: ld returned 1 exit status
configure:17892: $? = 1
configure: program exited with status 1
configure: failed program was:
| __thread int a; int b; int main() { return a = b; }
configure:18104: result: no




So, I guess,  the libgomp tests should not be built with TLS  
emulation ; and any test requiring TLS should be hidden behind a

{ dg-require-effective-target tls_runtime }

which was a proposal anyway ( http://gcc.gnu.org/ml/fortran/2008-12/ 
msg00155.html).




at least this will be consistent until such time as a general  
solution to making the emulation available is agreed.


(and that means addressing the general issues I raised earlier).

Iain

darwin, symbol visibility differences between libgcc_s and libgcc

[IainS]

Hi,

I've noticed that there are a few symbols that appear " T " from  
libgcc.a and " t " from libgcc_s.1.dylib.

(the exact set depends on ppc/intel and 32/64)

for example, on darwin9 (32 bit libs) the following;
___copysigntf3
___fabstf2
___udiv_w_sdiv
___unordtf2

Is there some specific reason it's done this way?
Iain

Re: darwin, symbol visibility differences between libgcc_s and libgcc

[IainS]

On 20 Dec 2008, at 03:51, Mike Stump wrote:


Yes, libgcc_s is carefully built with carefully controlled exports.  
They are controlled by:


  gcc/libgcc-std.ver

when someone wants to export one of the symbols, they can just add  
it to the list.


OK, my question was phrased poorly;
I understand the mechanism - what I don't understand is the rationale.

What is the benefit of splitting the publicly exported symbols  
between libgcc_s.1.dylib and libgcc.a?


This forces us to -lgcc, even in a hypothetical newly-released case,  
where the libgcc_s.1.dylib is completely up-to-date.


Iain

correct place for code.

[IainS]

Hi,

I need to make a test expanded from ASM_OUTPUT_LABEL_REF that is  
language dependent (on objc/objcxx).


It's not clear where the best/proper place to put the code is.

if I put it in  {stub,act}-objc.c that's fine for c, c++, objc and  
objc++ ...
... but it means that stub-objc then needs to be linked with jc1 and  
f951
... and anyway the test is target-specific so perhaps it belongs  
better somewhere in config/...


if I put it in config/target.c then the c_dialect variable  
(c_language) is not available from jc1 or  f951 - although,  
obviously, a dummy definition could be made to satisfy the reference.


Is there a "best practice" or "known way" to solve this?

cheers,
Iain

Re: correct place for code.

[IainS]

On 15 Jan 2009, at 01:44, Ian Lance Taylor wrote:

I need to make a test expanded from ASM_OUTPUT_LABEL_REF that is
language dependent (on objc/objcxx).


It's pretty hard to think of any reason why something as low-level as
ASM_OUTPUT_LABEL_REF would want to look at anything in the frontend.
You are probably working at the wrong level.


I'm entirely prepared to believe that...

The problem is this (on darwin):
(currently) ASM_OUTPUT_LABELREF modifies the generated label in  
certain cases (where the symbols are internal to OBJC)
When these symbols are mangled in obj-c++ it makes it a much more  
difficult to detect them reliably.

"knowing" that the symbols have been mangled improves that.

Without the change to the label name we get wrong generated code  
which causes a ld fail (responsible for a fair number of the 'new  
rash' of obj-c++ testsuite fails on darwin9)


So options:

1/ Do something target-specific in the generation of the labels and  
their subsequent mangling...

   maybe this is the Right Way ...
  However, I don't know my way around well enough to know how hard  
that would be - and it does seem quite intrusive.


2/ assume that no sensible user will make an intention external  
symbol named ZL_OBJC_xx
   perhaps that's not too unreasonable... OBJC_x are effectively  
reserved identifiers - so perhaps mangled file scope variants of  
those could be too.


3/ tell the backend that the names have been mangled
   the idea here was to generalize the c_language enum to a  
"gcc_language" enum and export it from each gcc language.


4/ some other way ...  any input is most appreciated,
Iain

missing gcc/testsuite/objc/execute/trivial.m?

[IainS]

Hi,
it seems that there's no "trivial.m" in  gcc/testsuite/objc/execute

a copy of that in gcc/testsuite/objc/execute/exceptions would work
Iain.


#import 

int main(void)
{
  [Object class];
  return 0;
}

Re: missing gcc/testsuite/objc/execute/trivial.m?

[IainS]

On 15 Jan 2009, at 20:40, Andrew Pinski wrote:


On Thu, Jan 15, 2009 at 12:13 PM, IainS
 wrote:

Hi,
it seems that there's no "trivial.m" in  gcc/testsuite/objc/execute


Hmm, this is only needed if execute.exp is run only I think.


that's true, and generally it's not noticed otherwise.

That's because, at the moment, the test for runtimes is only carried  
out once (when objc-torture.exp is loaded).


This doesn't seem quite right - because you get different results for  
"--target_board=unix\{-m32,-m64\} " and "--target_board=unix\{-m64,- 
m32\} "


I think the test should be run for each torture-init (and have a  
patch reg-testing at the moment to do this).


in the case that the test is done each time the .exp changes - then  
the trivial.m will be needed even if execute.exp is not used in  
isolation.


cheers,
Iain

Re: missing gcc/testsuite/objc/execute/trivial.m?

[IainS]

On 15 Jan 2009, at 20:57, Andrew Pinski wrote:


On Thu, Jan 15, 2009 at 12:51 PM, IainS
 wrote:

This doesn't seem quite right - because you get different results for
"--target_board=unix\{-m32,-m64\} " and "--target_board=unix\{- 
m64,-m32\} "


You should not get different results with those options.  At least on
any correct OS :).  If you are different results then you need a newer
version of Mac OS X really.  The GNU runtime works with both
-m32/-m64, it is only the NeXT runtime which does not always


it is Next cases I'm trying to tidy up - on the way to trying to  
reduce the number of fails on darwin9 (PR35165)


However, regardless of "correctness" of the OS or otherwise - surely,  
the runtime test should be carried out for each distinct set of  
User's requested test conditions?


Iain

Re: Linking libgfortran with libiberty

[IainS]

Richard,

On 29 Mar 2009, at 12:08, Richard Guenther wrote:


On Sun, Mar 29, 2009 at 1:00 PM, FX  wrote:

Hi all,

This mail is a request for some help from our local build machinery
experts... We have a patch under testing for libgfortran to add  
runtime
memleaks checking, and it uses libiberty's hash tables. So, we now  
link

gfortran programs with libiberty.


What do you mean by this?  Linking libiberty to programs build with
gfortran?  Note that libiberty is not installed by default IIRC.


That might be the intention - but (at least on OSX/Darwin)  
libiberty.a is installed, see also this thread for some elaboration  
on different permutations:

http://gcc.gnu.org/ml/gcc-help/2008-06/msg9.html

(I just built & installed from trunk on darwin9 and it is still the  
case that "make install" does this).


Iain

Different flags for building plugins and gcc.

[IainS]

On darwin (powerpc only at present, but potentially i686 too) we use "- 
mdynamic-no-pic" to build the compiler.


config/mh-ppc-darwin:
# The -mdynamic-no-pic ensures that the compiler executable is built  
without
# position-independent-code -- the usual default on Darwin. This fix  
speeds

# compiles by 3-5%.

BOOT_CFLAGS += -mdynamic-no-pic



This is fine until we try to build plugins.

plugins need fPIC which is overridden by mdynamic-no-pic (with a  
warning message emitted).
This means that the autoconfigury machinery defaults to deciding that  
ppc can't do plugins.


one cannot force the issue with --enable-plugins.

I've proved to myself that ppc makes and runs the plugins code  
perfectly OK (by hacking mh-ppc-darwin off).


=

However trying to find where exactly I need to patch the autoconfigury  
bits is proving more tricky - and I'd welcome some comments;


firstly:

in gcc/configure.ac:
  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  case "${host}" in
*-*-darwin*)
  LDFLAGS="$LDFLAGS -fPIC -shared -undefined dynamic_lookup"
;;
*)
  LDFLAGS="$LDFLAGS -fPIC -shared"
;;
  esac
  AC_MSG_CHECKING([for -fPIC -shared])

.. this seems a bit strange : -fPIC  is not a ld flag...

maybe something like:

  # Check that we can build shared objects with -fPIC -shared
  saved_LDFLAGS="$LDFLAGS"
  saved_CFLAGS="$CFLAGS"

  case "${host}" in
*-*-darwin*)
   CFLAGS=`echo $CFLAGS | sed s/-mdynamic-no-pic//g`
   CFLAGS="$CFLAGS -fPIC"
   LDFLAGS="$LDFLAGS -shared -undefined dynamic_lookup"
;;
*)
   CFLAGS="$CFLAGS -fPIC"
  LDFLAGS="$LDFLAGS -shared"
;;
  esac
  AC_MSG_CHECKING([for -fPIC -shared])

===

then Makefile.in has:

PLUGINCFLAGS = @CFLAGS@

I wonder if we need to propagate a PLUGINCFLAGS ?

or put some target-specific stuff there too .. ?

===

Are there any other places I need to look?

(I've only achieved partial success with the changes above ).

cheers,
Iain

Re: Different flags for building plugins and gcc.

[IainS]

Hi Ian,

On 12 May 2010, at 21:00, Ian Lance Taylor wrote:


IainS  writes:


.. this seems a bit strange : -fPIC  is not a ld flag...


LDFLAGS is flags that are passed to the compiler when linking.  It is
not flags passed directly to the linker.  I don't know why -fPIC is
there, but it shouldn't do any harm.


it's more that it's *not* force-added to CFLAGS that was a surprise -  
since that's one thing the code says it's testing.



The Makefile fragment config/mh-ppc-darwin is selected in
configure.ac.  I think the simplest approach would be to select
different config files based on whether --enable-plugins is used.



Agreed - it's the simplest .. but..

(a) that means we don't auto-detect the ability to use plugins - not a  
major bind, but a shame.


(b) if we believe that the comment in mh-ppc-darwin is up to date, we  
are sacrificing 3..5% compile performance if we build a compiler able  
to use plugins.


.. (b) also applies to the other simple approach - just nuke mh-ppc- 
darwin [which, incidentally,  restores auto-detect of plugin  
capability] ;-)


Iain

Re: Proposal: remove the Obj-C++ front end

[IainS]

No Asbestos required - but .. I do have some observations..

 I write pretty much all my serious (day-job) code in ObjC and..
...  I have stated that it's an intention to make *that*, at least  
work at V2 on FSF.


Having said that:

a)  I have not anything like as much attachment to ObjC++ ...
b) We are all limited in the amount of time we can allocate to FSF ..

Progress can be limited almost as much by the review lag as it is by  
technical difficulty in fixing the problems.


On 20 May 2010, at 20:02, Steven Bosscher wrote:

The Obj-C++ front end is effectively unmaintained, and has virtually
no serious users. I propose to remove it from GCC.


a) I'm curious about how we know how many actual users we have.

b) The largest group of potential users is on OSX - and, of course,  
without NeXT working on 64bit that's a serious limitation.


yay verily the chicken and the egg.

Also, I think it fair to say that "ordinary" users - like me have been  
reluctant to devote significant time to ObjC/C++

... when the likelihood of getting code accepted was c.f sqrt(0.0).

I would suggest that, if we achieve V2 NeXT support and detachment  
from corporate domination of maintainers ... we might fare better.

(but perhaps it's just not a popular language full stop).


Perhaps the only user of some significance is GNUstep, but they are
already in an awkward position because they wish to use ObjC 2.0, and
they are looking at clang for that.


I am under the impression from the 4.2 code-base that V2.0 ObjC++ will  
come pretty much for free with V2 ObjC.



The burden on GCC on the other hand, from a maintainer's point of
view, is very significant.


high maintenance  != unmaintained ;-)


The Obj-C++ front end ties
together the c, objc, and g++ front ends in very uncomfortable ways.


doesn't it just  :-( ... it's a nightmare to learn (1st hand  
experience).


It would be worth pausing to see if there's a way to disentangle it.
Which would, perhaps, go some way towards ameliorating the irritation.


There are also technical reasons for removing this front end. For one,
objc exceptions in objc++ don't work for the GNU runtime.


Well .. I have an opinion that don't != can't  ...  if you know this  
to be untrue I'd be interested.


... ObjC exceptions need sorting out..
I would hope that ObjC++ exceptions would 99% fall out of that.


The implementation of the language also appears to be out of sync with
Apple (apart from ObjC 2.0).


I'm not aware of any excess lack of sync c.f. ObjC

V1 requires FE __attribute__ and @property support (which I've got 95%  
working on a local tree)


V2 - I guess the most significant impact is gc.


I'll get in my flame resistant suit now...


So what about writing an Occam FE ;-) ?

Iain

Re: Proposal: remove the Obj-C++ front end

[IainS]

On 21 May 2010, at 10:12, Richard Guenther wrote:

On Thu, May 20, 2010 at 10:20 PM, Steven Bosscher > wrote:
On Thu, May 20, 2010 at 9:54 PM, IainS > wrote:

No Asbestos required - but .. I do have some observations..

 I write pretty much all my serious (day-job) code in ObjC and..
...  I have stated that it's an intention to make *that*, at least  
work at

V2 on FSF.

Having said that:

a)  I have not anything like as much attachment to ObjC++ ...
b) We are all limited in the amount of time we can allocate to  
FSF ..


Right. I am not suggesting ObjC should go away at all. It clearly has
users and it's pretty much isolated. It mixes with the C front end,  
of

course, but that is not a problem. With ObjC++, you have a front end
trying to unify the C, ObjC, and C++ front ends with itself. That's
not even comparable.

Besides, the ObjC language makes sense, whereas Obj-C++ combines the
worst of ObjC with the worst of C++ (or so I'm told by people who
should know what they're talking about ;-)


I thought Obj-C++ was most about ObjC - C++ interoperability
because all the OS-X UI runtime is written in ObjC which makes
it hard to write a pure C++ GUI application.


It's quite possible to do the Qt thing, and it's done successfully on  
OSX/Darwin - as is java gui.


However, that isn't the point.

Favorite flavors aside - assuming that one wishes to use ObjC as a  
development platform on Darwin, it is necessary at times to access  
important system components written in c++.   We should ensure that we  
don't lose this ability in whatever step is taken next.


It is also the case that a gnu-objc user on linux would wish to  
incorporate c++ - even the inverse of the darwin scenario.


In my ideal world, I would be able to write my gui in ObjC, leverage  
legacy C stuff, connect in my CFD code in Fortran and utilize open  
source c++ GIS code - in the same application.


(Of course, that's speaking as a User, rather than volunteering to  
implement it).


===

I'd argue for:
Please allow us the opportunity to make significant progress towards  
resolving the issues by end 4.6 ..


If that is not "significant enough" then we could fork the c++  
components of ObjC++ and detach it from the live c++ ..
... it would be stagnant but not dead (not much different from the  
state since 4.3).


I personally have a higher priority on ObjC - but would seriously  
expect that effort spent there will benefit ObjC++ ...


The code is currently 99% or so shared.

for example, ... we could macro-ize the differences in build_xxx  
rather then expecting c++ people to wrap things (I wasn't expecting it  
actually, ;-))


of course it isn't my call.. and I can't seriously volunteer to solve  
all the problems, but IMO there ought to be reasonable engineering  
solutions..

(as alternatives to rm -rf)
Iain

test-suite question, dg-final/scan-file on objects?

[IainS]

Hi,

In the Obj{C,C++} testsuite we have cases where we want to check for  
reasonably long ascii strings in generated data.


At present, this is done in some places by dg-final/scan-assembler  
constructs, but these can (and do) fail when the target assembler  
breaks long strings into shorter concatenated segments.


One solution is target-specific scan-assembler statements, but makes  
the test cases less readable and more prone to maintenance error.


A nicer (and, in a way, more correct) solution would be to use scan- 
file to match for the string in the object.


dg-final/scan-file seems to work on all the targets I've got access  
to...
... however, grep tells me that scan-file is usually used on ".i"  
rather than ".o" files ... so I'd like to ask:


"Is it an accepted approach to use scan-file on objects? "  ... or
"Is there an equivalent to scan-file specifically targeted at  
objects?" (nothing leaps out at me in the doc./google)


cheers
Iain

complete list of emulated TLS targets.

[IainS]

I'd like to compile a complete list of targets affected by changes in  
emulated TLS.


*-*-darwin*
hppa64-hp-hpux11.11
cris-*-elf

I think also;

*-*-mingw
*-*-cygwin

could people please add to the list/confirm as appropriate?
thanks
Iain

How to pass a pathlist in RUNTESTFLAGS?

[IainS]

Hi,

I want to do this:
	RUNTESTFLAGS="--target_board=unix/-foo/-bar/--sysroot=/path/to/ 
somewhere "


I've tried escaping the path with \ ' inverting the " and ' ..  all to  
no avail ..


 what gets passed is -foo -bar --sysroot= -mpath -mto -msomewhere ..

google hasn't helped..

anyone know what incantation I've missed?
cheers,
Iain

Re: How to pass a pathlist in RUNTESTFLAGS?

[IainS]

On 9 Jul 2010, at 17:28, Manuel López-Ibáñez wrote:


On 9 July 2010 16:55, Doug Semler  wrote:
On Fri, Jul 9, 2010 at 9:12 AM, IainS > wrote:

Hi,

I want to do this:

 RUNTESTFLAGS="--target_board=unix/-foo/-bar/--sysroot=/path/to/ 
somewhere "


I've tried escaping the path with \ ' inverting the " and ' ..   
all to no

avail ..

 what gets passed is -foo -bar --sysroot= -mpath -mto -msomewhere ..

google hasn't helped..

anyone know what incantation I've missed?
cheers,
Iain



IIRC i needed something like (can't remember offhand if this is
exactly it, but it's something like this...)

RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere
--target_board=unix/-foo/-bar"



Please, once you find out, add this info to http://gcc.gnu.org/wiki/Testing_GCC


I really must sign up ... ;-)

FWIW:

RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere
--target_board=unix/-foo/-bar"

does work  but maybe:

RUNTESTFLAGS="CFLAGS_FOR_TARGET='$CFLAGS_FOR_TARGET   --sysroot=/path/ 
to/somewhere'  --target_board=unix/-foo/-bar"


is safer? -- CFLAGS_FOR_TARGET could already be set, I guess.

both work in the context I needed.

thanks,
Iain

Re: How to pass a pathlist in RUNTESTFLAGS?

[IainS]

On 9 Jul 2010, at 17:28, Manuel López-Ibáñez wrote:


RUNTESTFLAGS="CFLAGS_FOR_TARGET=--sysroot=/path/to/somewhere
--target_board=unix/-foo/-bar"



Please, once you find out, add this info to http://gcc.gnu.org/wiki/Testing_GCC


done (and amended the sim. section to refer to the second simulator  
page),
would you like to give it a "once over" in case I've missed a  
stylistic requirement?

thanks
Iain

specs and X-s and canadian X-s.

[IainS]

When doing native bootstraps things are nice and easy ...  the target  
spec  definitions are also appropriate for the host.


===

I've been doing some canadian X-s  (specifically darwin 9 => darwin 7).

So, ... when doing B == H != T  the specs might need to be different  
from  B != H == T (or B=H=T)


In effect the specs for the linker are used to generate code for the  
'target' on the 'host'.


the problem comes when the B-host needs different specs from the  
native case.


So when doing   B == H != T (first cross - to build a compiler capable  
of making T code on B) we need specs that the B understands
(this all works quite easily using --with-sysroot= .. etc. - and needs  
to use the right specs to allow generation on the B system)
[ a specific case is inserting a path spec to point to the sysroot -  
which the B linker understands]


When doing B != H == T (second cross - to make the compiler for T  
hosted on T) we need to generate native specs that T understands.

[in my example the path spec causes the T==H linker to fail]

===

Is it legitimate to wrap these circumstances with #ifndef  
CROSS_DIRECTORY_STRUCTURE ... #endif  in the target headers.

(or maybe there's a flag somewhere that indicates H == T ?)

I recognize that this is changing the target headers depending on the  
host ..
..  but at the moment I can't see how else to do it; the specs say "do  
'this' to generate correct code for the target"

..  but "this" might well be host-dependent.

It doesn't seem to belong in confg/mh-* or gcc/config/x-*

any insight much appreciated.

Iain

Re: split stack on darwin

[IainS]

On 28 Sep 2010, at 17:29, Ian Lance Taylor wrote:


Jack Howarth  writes:

 Does the new split stack feature in gcc trunk absolutely require  
additional
libc support to function or can it be made to work on other targets  
like

darwin with just changes to libgcc? Thanks in advance for any
clarifications.


The additional support that it needs is a thread local place to store
the stack bound which can be accessed efficiently.  On GNU/Linux I'm
using a word in the thread block--I've actually stolen a word which  
was

reserved for transactional memory but which RTH says he doesn't need.
This can be accessed as an offset from %fs or %gs.  To make this
functionality work on Darwin, you need something similar.  I don't  
know
how thread local storage works on Darwin, so I don't know if you can  
do

something similar.


We have emulated TLS (Richard's new code) .


I list some other options at http://gcc.gnu.org/wiki/SplitStacks under
"Possible strategies.



I sincerely doubt something this involved can be accommodated in the  
remaining time of stage 1

(unless we magic some additional Darwin devs from somewhere ;-))

Iain

Re: Discussion about merging Go frontend

[IainS]

On 29 Oct 2010, at 09:56, Dave Korn wrote:

This implements an object file reader/writer which does everything
required by LTO and gccgo.  The ELF code works.  I have not tested  
the

Mach-O and COFF code at all beyond compiling it; I hope that somebody
else can test those targets and fix them.


 I'm right here :) Can't help with Darwin but hopefully Jack/Iain  
will be

available.



I tried with 166058 on ppc-darwin9 (my other machines are tied up  
right now)


-flto fails on link with missing _main.
e.g:
Executing on host: /Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/xgcc -B/ 
Volumes/ScratchCS/gcc-4-6-trunk-build/gcc/ c_lto_20081024_0.o  -

O0 -flto   -m32 -o gcc-dg-lto-20081024-21(timeout = 60)
Undefined symbols:
  "_main", referenced from:
  start in crt1.10.5.o

-whopr ices with:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
0x007f8e18 in objfile_mach_o_find_sections (objfile=0x40e078b0,  
pfn=0x1d7ec , data=0xb19c, err=0xb198)  
at /GCC/gcc-live-trunk/libiberty/objfile-mach-o.c:469

469   memcpy (name, sechdr + sectname_offset, MACH_O_NAME_LEN);
(gdb) bt
#0  0x007f8e18 in objfile_mach_o_find_sections (objfile=0x40e078b0,  
pfn=0x1d7ec , data=0xb19c, err=0xb198)  
at /GCC/gcc-live-trunk/libiberty/objfile-mach-o.c:469
#1  0x007f5dbc in objfile_find_sections (objfile=unavailable, due to optimizations>, pfn=unavailable, due to optimizations>, data=unavailable, due to optimizations>, err=unavailable, due to optimizations>) at /GCC/gcc-live-trunk/libiberty/ 
objfile.c:173
#2  0x0001dc60 in lto_obj_build_section_table (lto_file=temporarily unavailable, due to optimizations>) at /GCC/gcc-live-trunk/ 
gcc/lto/lto-objfile.c:270
#3  0x0001af80 in lto_read_all_file_options () at /GCC/gcc-live-trunk/ 
gcc/lto/lto.c:2052
#4  0x3960 in lto_post_options (pfilename=unavailable, due to optimizations>) at /GCC/gcc-live-trunk/gcc/lto/lto- 
lang.c:709
#5  0x004f0eec in toplev_main (argc=15, argv=Cannot access memory at  
address 0x1c

) at /GCC/gcc-live-trunk/gcc/toplev.c:1778
#6  0x1944 in start ()

if you need more analysis - ping me with what and I'll try and do sth  
-- or maybe Jack can help with a user on his machine.


cheers,
Iain

4.3.1 fixincludes observation.

[IainS]

Hello all,

Supplement to :
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00543.html
http://gcc.gnu.org/ml/gcc-testresults/2008-06/msg00542.html

Since this is not (AFAICT) reported by test summary;
Most of it seems to be (presumably harmless) differences in white space.

However note at the end " Missing header fix:  pthread.h"

Applies to {powerpc,i686}-apple-darwin8.

Is this relevant?

Iain

=

autogen -T /Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/check.tpl / 
Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/inclhack.def
/bin/sh ./check.sh /Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/ 
tests/base

Fixed:  testing.h
Fixed:  testing.h
Fixed:  AvailabilityMacros.h
Fixed:  X11/ShellP.h
Fixed:  X11/Xmu.h
Fixed:  Xm/BaseClassI.h
Fixed:  Xm/Traversal.h
Fixed:  _G_config.h
Fixed:  ansi/math.h
Fixed:  ansi/stdlib.h
Fixed:  arch/i960/archI960.h
Fixed:  architecture/ppc/math.h
Fixed:  arpa/inet.h
Fixed:  assert.h
Fixed:  bits/huge_val.h
Fixed:  bits/string2.h
Fixed:  bsd/libc.h
Fixed:  c_asm.h
Fixed:  com_err.h
Fixed:  ctrl-quotes-def-1.h
Fixed:  ctype.h
Fixed:  curses.h
Fixed:  errno.h
Fixed:  features.h
Fixed:  fixinc-test-limits.h
Fixed:  fs/rfs/rf_cache.h
Fixed:  hsfs/hsfs_spec.h
Fixed:  ia64/sys/getppdp.h
Fixed:  internal/math_core.h
Fixed:  internal/sgimacros.h
Fixed:  internal/wchar_core.h
Fixed:  inttypes.h
Fixed:  io-quotes-def-1.h
Fixed:  iso/math_c99.h
Fixed:  locale.h
Fixed:  mach-o/dyld.h
Fixed:  mach-o/swap.h
Fixed:  machine/cpu.h
Fixed:  malloc.h
Fixed:  math.h
Fixed:  netdnet/dnetdb.h
Fixed:  netinet/in.h
Fixed:  netinet/ip.h
Fixed:  obstack.h
Fixed:  pixrect/memvar.h
sed: 1: "/define[   ]\+PTHREAD_MU ...": expected context address
Fixed:  reg_types.h
Fixed:  regex.h
Fixed:  regexp.h
Fixed:  rpc/auth.h
Fixed:  rpc/rpc.h
Fixed:  rpc/svc.h
Fixed:  rpc/xdr.h
Fixed:  rpcsvc/rstat.h
Fixed:  rpcsvc/rusers.h
Fixed:  signal.h
Fixed:  sparc/asm_linkage.h
Fixed:  standards.h
Fixed:  stdint.h
Fixed:  stdio.h
Fixed:  stdio_tag.h
Fixed:  stdlib.h
Fixed:  string.h
Fixed:  strings.h
Fixed:  sundev/vuid_event.h
Fixed:  sunwindow/win_lock.h
Fixed:  sym.h
Fixed:  sys/asm.h
Fixed:  sys/cdefs.h
Fixed:  sys/file.h
Fixed:  sys/ioctl.h
Fixed:  sys/limits.h
Fixed:  sys/machine.h
Fixed:  sys/mman.h
Fixed:  sys/pthread.h
Fixed:  sys/regset.h
Fixed:  sys/signal.h
Fixed:  sys/socket.h
Fixed:  sys/spinlock.h
Fixed:  sys/stat.h
Fixed:  sys/sysmacros.h
Fixed:  sys/time.h
Fixed:  sys/times.h
Fixed:  sys/types.h
Fixed:  sys/ucontext.h
Fixed:  sys/utsname.h
Fixed:  sys/wait.h
Fixed:  testing.h
Fixed:  time.h
Fixed:  tinfo.h
Fixed:  types/vxTypesBase.h
Fixed:  unistd.h
Fixed:  wchar.h
Fixed:  widec.h
Xm/Traversal.h /Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/tests/ 
base/Xm/Traversal.h differ: char 296, line 15

*** Xm/Traversal.h  Sat Jun  7 02:20:03 2008
--- /Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/tests/base/Xm/ 
Traversal.h Tue Aug 31 10:27:00 2004

***
*** 12,18 
  #if defined( X11_NEW_CHECK )
  struct wedge {
  #ifdef __cplusplus
! Widgetold, c_new;
  #else
 Widget old, new; /* fixinc check FAILS ON BSD */
  #endif
--- 12,18 
  #if defined( X11_NEW_CHECK )
  struct wedge {
  #ifdef __cplusplus
!   Widget  old, c_new;
  #else
 Widget old, new; /* fixinc check FAILS ON BSD */
  #endif
strings.h /Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/tests/base/ 
strings.h differ: char 687, line 31

*** strings.h   Sat Jun  7 02:20:03 2008
--- /Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/tests/base/ 
strings.h  Tue Aug 31 10:27:00 2004

***
*** 28,39 
strncmp( const char *__s1, const char *__s2, size_t __n );

  extern int
! strcasecmp( const char *__s1, const char *__s2),
! strncasecmp( const char *__s1, const char *__s2, size_t __n );
strncmp();
  extern int
! strcasecmp(),
! strncasecmp();

  #endif  /* ULTRIX_STRINGS2_CHECK */

--- 28,39 
strncmp( const char *__s1, const char *__s2, size_t __n );

  extern int
!   strcasecmp( const char *__s1, const char *__s2),
!   strncasecmp( const char *__s1, const char *__s2, size_t __n );
strncmp();
  extern int
!   strcasecmp(),
!   strncasecmp();

  #endif  /* ULTRIX_STRINGS2_CHECK */

sys/stat.h /Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/tests/base/ 
sys/stat.h differ: char 432, line 18

*** sys/stat.h  Sat Jun  7 02:20:03 2008
--- /Volumes/UFSScratch/GCC/gcc-4.3.1/fixincludes/tests/base/sys/ 
stat.h Mon Mar 26 14:25:26 2007

***
*** 15,21 


  #if defined( GLIBC_C99_INLINE_2_CHECK )
! extern int fstat64 (int __fd, struct stat64 *__buf) __THROW  
__nonnull ((2));

  #ifdef __GNUC_GNU_INLINE__
  extern
  #endif
--- 15,24 


  #if defined( GLIBC_C99_INLINE_2_CHECK )
! #ifdef __GNUC_GNU_INLINE__
! extern
! #endif
! __inline__ int fstat64 (int __fd, struct stat64 *__buf) __THROW  
__nonnull ((2));

  #ifdef __GNUC_GNU_INLINE__
  extern
  #endif
***
*** 39,45 
return __stat32(__f, __p);
  }
  #if __cpluspl

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[IainS]

On 10 Jun 2008, at 17:11, FX wrote:

I opted to call the static library "libgfortran_static" and to  
leave the shared name unchanged.


I'd suggest "-static" instead of using an underscore, to follow  
libstdc++, but that's a minor point.


A minor point maybe, but, as you say, there seem to be several  
different schemes in use... a source of confusion for me whilst  
trying to figure out how to do this.


I was almost going to rename the shared one _s (as per libgcc) :-)

j/k aside is there a convention ?

I don't mind (I prefer '-' to '_' personally;'_static'  and  
'_kext' were used in the 4.0.1 vendor release for darwin8).


Otherwise, wrt your patch: doesn't it create three libraries:  
libgfortran.dylib, libgfortran.a and libgfortran_static.a? And,  
what happens now if you do a -static compilation, does it pick  
libgfortran_static automagically? Shouldn't we make that darwin- 
specific, in order to not change the situation on the majority of  
other systems that don't have a problem with the current situation?


Yes, it does make three libs - only a temporary measure to avoid  
treading on anyone else whilst testing (see below).


The "-static-libgfortran" option causes it to pick up the _static  
version  (patch to gfortranspec.c).


AFAIK there is no point in doing a "-static" link on darwin [crt0 is  
not present] (unless you're making a kernel extension).
However, the proposed change makes no difference to what will happen  
if you do.


You are right;  of course, it should be darwin-specific (and only  
build the required libs per system)
-  but I am not familiar enough with the build process to know how  
best to achieve that... suggestions welcome.


Iain

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[IainS]

On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:


Hello,

* FX wrote on Tue, Jun 10, 2008 at 05:59:36PM CEST:

De : IainS <[EMAIL PROTECTED]>

I opted to call the static library "libgfortran_static" and to leave
the shared name unchanged.

It would be great if libtool could be persuaded to change the  
basename

as well as the extension for the dynamic/static
but despite RTFM and googling I can't seem to find any example of  
how

to achieve that in an easy manner.


It doesn't do that because that breaks the abstraction.  It might also
increase a bit the risk of ending up with bits of the static library
included, and bits of shared deplibs you use pulling in the shared
version of the library.


OK, I appreciate the first part;
I don't immediately understand how  libfoo-static.a  is any more  
dangerous than libfoo.a

or libfoo-s.dylib   libfoo.so


Can the driver use path/to/libgfortran.a instead of '-Lpath/to
-lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic?


this doesn't appear to work. [I've unset DYLD_LIBRARY_PATH in the  
following]


 ./dst-powerpc/usr/bin/gfortran-4.4.0 helloi.F90 /Volumes/UFSScratch/ 
GCC/gcc-44-build/dst-powerpc/usr/lib/gcc/powerpc-apple-darwin8/4.4.0/ 
libgfortran.a -o helloif


thor:/Volumes/UFSScratch/GCC/gcc-44-build $ ./helloif

dyld: Library not loaded: /usr/lib/gcc/powerpc-apple-darwin8/4.4.0/ 
libgfortran.3.dylib

  Referenced from: /Volumes/UFSScratch/GCC/gcc-44-build/./helloif
  Reason: image not found
Trace/BPT trap

it appears to be ignoring my directly-specified library and linking  
in the dynamic one anyway.


we could campaign for a different linker on OSX/Darwin I guess...
... but it seems that ld64 is the vendor's preferred solution (given  
the publicly released source for 10.5)



Independently, does anybody know whether odcctools is dead (homepage
seems to be down ATM)?
<http://thread.gmane.org/gmane.comp.gnu.libtool.general/7158/ 
focus=7173>


macports does install this; although it doesn't understand m64 mach-o  
(at least objdump doesn't)
The difficulty becomes that one cannot supply something that is  
compatible with the vendor's standard installation.


We start to require that the end user has administration rights to  
install into /usr simply in order to run a program?


It is possible to accommodate the required lib name change at  
install

time by renaming libgfortran.a and ranlib-ing the new one.


Don't try this on AIX, where libtool may create a shared archive with
that name.


OK. - so the solution as I have it is in the right direction...  (bar  
removing the extra static lib).


I agree with FX that it would be nice to limit a change to Darwin  
if at

all.


-static-libgcc works on darwin.
it's accommodated by different libnames.
I don't know if that change extends to other triplets - at present I  
only have OSX machines to hand.



Cheers,
Ralf


thanks for your responses,
Iain

Re: [RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[IainS]

On 10 Jun 2008, at 20:58, Ralf Wildenhues wrote:


* IainS wrote on Tue, Jun 10, 2008 at 09:42:29PM CEST:

On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:


Can the driver use path/to/libgfortran.a instead of '-Lpath/to
-lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic?


this doesn't appear to work. [I've unset DYLD_LIBRARY_PATH in the
following]

 ./dst-powerpc/usr/bin/gfortran-4.4.0 helloi.F90 /Volumes/UFSScratch/
GCC/gcc-44-build/dst-powerpc/usr/lib/gcc/powerpc-apple-darwin8/4.4.0/
libgfortran.a -o helloif


Well, what I meant was that on Dargin, gfortran could pass the  
argument

  path/to/libgfortran.a

to collect2, instead of passing
  -Bstatic -lgfortran -Bdynamic


I guess.. [I'll have to try this another day ]
you can do "-nodefaultlibs" and then specify all the libs by hand.   
That works (I originally did this).

It seems then that the driver has to replicate the multilibs stuff...

I'm not sure that it would produce less darwin-specific code than  
renaming the lib.



we could campaign for a different linker on OSX/Darwin I guess...


What's the problem with just using the shared library?
(Yeah, I knew that question was naive ... but hey, it works ;-)


I'm also happy to file a radar for missing Bstatic/Bdynamic.


We start to require that the end user has administration rights to
install into /usr simply in order to run a program?


I'm not sure whether I understand this comment.  Isn't the link-time
location of a shared library added to the search path anyway?
(My experience with darwin is quite limited, so my memory may serve
me wrong here.)


fortran is not part of any standard installation on OSX (yet..., of  
course, that could change).

On darwin 8 the gcc version is 4.0.1
I don't know whether the 4.2.1 version [from darwin 9] will be  
officially released

...  I've back-ported it (but, that's not an end-user thing)

if you want to deliver any different you have to choose
(a) the end user must install with admin rights  [to put stuff in / 
usr etc.]

(b) static linking of the missing bits

(b) is a lot simpler for me...

ttfn,
Iain

[patch, howto, gfortan] make check fix ppc64/darwin8

[IainS]

I came across a "gotcha" whilst trying to test the static  
implementation of libgfortran on PPC64-apple-darwin8.

Thanks to Tobias B for pointing me at 99% of the solution.

Probably the number of affected systems is small ;) - but, FWIW,  
here's HOWTO and a fix.


-
If you host on {powerpc, i686}-apple-darwin8 and you want to static  
link (or check libgfortran) -m64 for PPC64  then this applies to you.


There is an incompatibility [presumably in ld64] between the default  
debug symbol generation (stabs) and what's required
for linking/checking PPC64 on darwin8 ...  this incompatibility  "is  
not going to be fixed".


The specific crunch is that every -O3  torture test is compiled with -g
   =>  in gfortran this causes every -O3 torture test to fail when  
checking -m64.




The solution is to build the required code with -gdwarf-2,  
unfortunately the "-g" flag is hard-coded in a couple of relevant  
places:


(a) in  "fortran-torture.exp"  and in "gcc-dg.exp" (which is included  
in gfortran-dg.exp)

[ the change to gcc-dg.exp makes this non-local to gfortran ]

(b) in the top level configure (as a default C/CXX/FLAGS_FOR_TARGET).

The minimum change work-around is this:

1/ configure/make gcc with CFLAGS_FOR_TARGET = "-02 -gdwarf-2 - 
pipe" (and CXXFLAGS_FOR_TARGET the same)


2/ apply the following :

Index: gcc/testsuite/lib/gcc-dg.exp
===
--- gcc/testsuite/lib/gcc-dg.exp(revision 136861)
+++ gcc/testsuite/lib/gcc-dg.exp(working copy)
@@ -48,9 +48,15 @@
{ -O2 } \
{ -O3 -fomit-frame-pointer } \
{ -O3 -fomit-frame-pointer -funroll-loops } \
-   { -O3 -fomit-frame-pointer -funroll-all-loops -finline- 
functions } \

-   { -O3 -g } \
-   { -Os } ]
+   { -O3 -fomit-frame-pointer -funroll-all-loops -finline- 
functions } ]

+
+   if { [istarget "*-*-darwin8"] } {
+   lappend DG_TORTURE_OPTIONS  { -O3 -gdwarf-2 }
+   } else {
+   lappend DG_TORTURE_OPTIONS  { -O3 -g }
+   }
+
+   lappend DG_TORTURE_OPTIONS { -Os }
 }

 global GCC_UNDER_TEST
Index: gcc/testsuite/lib/fortran-torture.exp
===
--- gcc/testsuite/lib/fortran-torture.exp   (revision 136861)
+++ gcc/testsuite/lib/fortran-torture.exp   (working copy)
@@ -73,9 +73,16 @@
{ -O2 } \
{ -O2 -fomit-frame-pointer -finline-functions } \
{ -O2 -fomit-frame-pointer -finline-functions -funroll- 
loops } \

-   { -O2 -fbounds-check } \
-   { -O3 -g } \
-   { -Os }
+   { -O2 -fbounds-check }
+
+   if { [istarget "*-*-darwin8"] } {
+   lappend options  { -O3 -gdwarf-2 }
+   } else {
+   lappend options  { -O3 -g }
+   }
+
+   lappend options { -Os }
+
 if { $test_tree_vectorize } {
lappend options $vectorizer_options
 }


*
COMPARISONs of make check-host with and without the changes

This is on darwin 8.11.0

*
make check-host   (default, m32)
one extra pass, no regressions
*

g++
-
no change

gcc
-
one extra pass from using dwarf-2
FAIL: gcc.dg/pch/save-temps-1.c  -O3 -g  assembly comparison
PASS: gcc.dg/pch/save-temps-1.c  -O3 -gdwarf-2  assembly comparison

gfortran
--
no change

obj-c++
--
no change

obj-c
--
no change


*
make check-host   (m64) RUNTESTFLAGS="--target_board=unix/-m64"
69 extra passes, no regressions
*

g++
--
one extra pass from using dwarf-2
FAIL: g++.old-deja/g++.eh/badalloc1.C execution test (-g)
PASS: g++.old-deja/g++.eh/badalloc1.C execution test (-gdwarf-2)

gcc
-
one extra pass from using dwarf-2
FAIL: gcc.dg/pch/save-temps-1.c  -O3 -g  assembly comparison
PASS: gcc.dg/pch/save-temps-1.c  -O3 -gdwarf-2  assembly comparison

gfortran (every test with -O3 -g fails )
--
67 extra passes using -gdwarf-2

=== gfortran Summary  (-g) ===

# of expected passes26196
# of unexpected failures85
# of expected failures  46
# of unsupported tests  59
/Volumes/SwapScratch/OS-source/gcc-44-build/n2n/gcc/testsuite/ 
gfortran/../../gfortran  version 4.4.0 20080612 (experimental) (GCC)


=== gfortran Summary (-gdwarf-2)  ===

# of expected passes26263
# of unexpected failures18
# of expected failures  46
# of unsupported tests  59
/Volumes/SwapScratch/OS-source/gcc-44-build/n2n/gcc/testsuite/ 
gfortran/../../gfortran  version 4.4.0 20080612 (experimental) (GCC)


obj-c++
--
no change

obj-c
--
no change


I guess, there's one residual puzzle to me;   from the doc. I'd  
understand that the -O3 optimizations are in the back end and therefore
common to all the tools.  Ho

[patch V2 gfortran] make -static-libgfortran work on darwin.

[IainS]

Thanks for all the helpful suggestions made in response to :
http://gcc.gnu.org/ml/gcc/2008-06/msg00244.html

--
Here is version 2 of the patch.

This is now conditional on darwin* as the host.
(I guess, in principle, it should really depend on LD_FOR_TARGET, but  
I couldn't see how to achieve that tidily).


to implement it requires:
a change to the gfortran driver.
a change to the build of libgfortran.

---
a. I've made the change to the driver such that any other host  
requiring this only need to define a flag in its x-host.
b. this "USE_DISTINCT_STATIC_LIB_NAME" flag is also available for any  
other front ends that want to cater for this darwin 'feature'.

---

change summary:

	gcc/config/x-darwin : add a flag identifying this as a system  
wanting separate static lib names
	gcc/fortran/gfortranspec.c : provide for a distinct static library  
name on -static-libgfortran


	libgfortran/Makefile.am : generate differently named static/dynamic  
libraries on darwin

libgfortran/configure.ac: likewise


*I have NOT attached the following generated file diffs (it made a  
huge mail, and conveys no extra info):

Index: libgfortran/configure
Index: libgfortran/Makefile.in
Index: libgfortran/config.h.in
Index: libgfortran/aclocal.m4

if anyone wants them - I can email them g/b/zip.

otherwise, to replicate what I did run autoreconf in libgfortran with :

 autoconf (GNU Autoconf) 2.61,
 automake (GNU automake) 1.9.6,
 ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.492 2008/01/30 06:40:56)

*
TESTS carried out;

This has been bootstrapped on:
powerpc-apple-darwin9
powerpc-apple-darwin8
i686-apple-darwin8

cross tools have also been built on those platforms.

it has been checked by comparing RUNTESTFLAGS="--target_board=unix/- 
static-libgfortran" with the default on


powerpc-apple-darwin9  [m32, m64]

powerpc-apple-darwin8 [m32, m64 ***]
i686-apple-darwin8

*** note you need to do this : http://gcc.gnu.org/ml/gcc/2008-06/ 
msg00361.html for m64 tests


no regressions noted.

=
Missing tests:
1/ a non-darwin system (sorry, don't have one up at the moment).

2/ x86_64 darwin8
3/ i686/x86_64 darwin9

*

Index: gcc/config/x-darwin
===
--- gcc/config/x-darwin (revision 136861)
+++ gcc/config/x-darwin (working copy)
@@ -1,3 +1,5 @@
+# for static lib on gfortran
+T_CFLAGS += "-DUSE_DISTINCT_STATIC_LIB_NAME"
 host-darwin.o : $(srcdir)/config/host-darwin.c $(CONFIG_H) $ 
(SYSTEM_H) \

   coretypes.h toplev.h config/host-darwin.h
$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $<


Index: gcc/fortran/gfortranspec.c
===
--- gcc/fortran/gfortranspec.c  (revision 136861)
+++ gcc/fortran/gfortranspec.c  (working copy)
@@ -62,21 +62,40 @@
 #define FORTRAN_INIT "-lgfortranbegin"
 #endif

-#ifndef FORTRAN_LIBRARY
-#define FORTRAN_LIBRARY "-lgfortran"
+#ifndef FORTRAN_SHARED_LIBRARY
+#define FORTRAN_SHARED_LIBRARY "-lgfortran"
 #endif

+#ifdef USE_DISTINCT_STATIC_LIB_NAME
+#  ifndef FORTRAN_STATIC_LIBRARY
+#define FORTRAN_STATIC_LIBRARY "-lgfortran-static"
+#  endif
+#else
+#  define FORTRAN_STATIC_LIBRARY FORTRAN_SHARED_LIBRARY
+#endif
+
 #ifdef HAVE_LD_STATIC_DYNAMIC
-#define ADD_ARG_LIBGFORTRAN(arg) \
+#define ADD_ARG_LIBGFORTRAN \
   { \
-if (static_lib && !static_linking) \
-  append_arg ("-Wl,-Bstatic"); \
-append_arg (arg); \
-if (static_lib && !static_linking) \
-  append_arg ("-Wl,-Bdynamic"); \
+   if (static_lib) \
+ { \
+   if (!static_linking) append_arg ("-Wl,-Bstatic"); \
+   append_arg(FORTRAN_STATIC_LIBRARY) ; \
+   if (!static_linking) append_arg ("-Wl,-Bdynamic"); \
+ } \
+   else \
+ { \
+   append_arg(FORTRAN_SHARED_LIBRARY) ; \
+ } \
   }
 #else
-#define ADD_ARG_LIBGFORTRAN(arg) append_arg (arg);
+#define ADD_ARG_LIBGFORTRAN \
+  { \
+   if (static_lib) \
+  append_arg(FORTRAN_STATIC_LIBRARY) ; \
+   else \
+  append_arg(FORTRAN_SHARED_LIBRARY) ; \
+  }
 #endif


@@ -265,9 +284,9 @@
   int skip;
   const char *arg;

-  /* This will be NULL if we encounter a situation where we should not
- link in libf2c.  */
-  const char *library = FORTRAN_LIBRARY;
+  /* 0 => don't link libgfortran etc.
+ 1 => link libgfortran version as determined by static_lib */
+  int should_link_libs = 1;

   /* 0 => -xnone in effect.
  1 => -xfoo in effect.  */
@@ -346,7 +365,7 @@
case OPTION_E:
  /* These options disable linking entirely or linking of the
 standard libraries.  */
- library = 0;
+ should_link_libs = 0;
  break;

case OPTION_static_libgfortran:
@@ -411,7 +430,7 @@

   /* If there are no input files, no need for the library.  */
   if (n_infiles == 0)