summaryrefslogtreecommitdiff
path: root/open_issues/gcc.mdwn
blob: 3aa7b63b6249e90a874d5a89ec73c989593357e3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free
Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_gcc]]

Here's what's to be done for maintaining GCC.

Apart from the target-specific configuration machinery, there shouldn't be any
major differences within GCC between the GNU/Hurd and GNU/Linux ports, for
example.  Especially all the compiler magic is all the same.

[[!toc levels=2]]


# [[General information|/gcc]]


# [[Sources|source_repositories/gcc]]


# Configuration

<!--

git checkout reviewed
git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..upstream/master | awk '/^diff/ { c = $0; } /^@@/ { print c; } { print; }' | less
-i
/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:

-->

Last reviewed up to the [[Git mirror's 0479dc77cf50ee78769b55563051cf72d39b3d60
(2013-05-27) sources|source_repositories/gcc]].

<http://gcc.gnu.org/install/configure.html> has documentation for the
`configure` switches.

  * Configure fragments that have `*linux*` cases might/should often contain
    those for us (and GNU/k*BSD) as well.

      * `configure.ac`

      * `libgomp/configure.tgt`

      * `libstdc++-v3/configure.host`

        `abi_baseline_pair` etc. setting.

      * `libstdc++-v3/config/os/gnu-linux/*`

        Is used for all GNU systems, as per `libstdc++-v3/configure.host`.
        Should rename to `gnu-user` to reflect this?

      * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for
        x86 Linux.  (Why?)

  * `hurd/usr`

    `NATIVE_SYSTEM_HEADER_DIR`, `638454a19c1c08f01c10517bc72a114250fc4f33`,
    [[!message-id "mcrzkhcbftp.fsf@coign.corp.google.com"]].

    Debian.

      * Eventually: get rid of this special-casing.  [[!message-id
        "gckk1s$e0b$1@ger.gmane.org"]].

  * [[`libmudflap`|libmudflap]].

  * [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html)

      * Also see `libgcc/config/i386/morestack.S`: comments w.r.t
        `TARGET_THREAD_SPLIT_STACK_OFFSET`/`%gs:0x30` usage; likely needs
        porting.

      * As per `libgcc/config/i386/t-stack-i386`, the former file is only used
        for `-fsplit-stack` support -- which is currently enabled for us in
        `libgcc/config.host`.

      * `gcc/config/gnu-user.h` defines `*SPLIT_STACK*` macros -- which aren't
        valid for us (yet), I think.

      * Also see [[sourceware_PR 10686]], glibc commit
        ecbf434213c0333d81706074e4d107ac45011635 `Reserve new TLS field for x86
        and x86_64` (`__private_ss`).

      * Might `-fsplit-stack` be useful for us with respect to our
        [[multithreaded|multithreading]] libraries?

  * `--enable-languages=[...]`

      * [[Ada (GNAT)|GNAT]] support is work in progress.

      * The [[Google Go's libgo|gccgo]] (introduced in
        e440a3286bc89368b8d3a8fd6accd47191790bf2 (2010-12-03)) needs
        OS configuration / support.

  * `--enable-frame-pointer`

    `gcc/configure.ac`: `enable_frame_pointer=no`

  * `--with-dwarf2`?

  * `--enable-werror`

  * `--enable-checking`

  * `--enable-linker-build-id`

  * `--enable-gnu-unique-object`

  * `--enable-lto`

  * `--enable-indirect-function`

    [[IFUNC]]

  * <http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html>,
    <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00672.html>

      * `gcc/config/t-linux` should be named `gcc/config/t-gnu-user` or
        similar.  Likewise for `gcc/config/i386/t-linux`.

  * Debian's GCC package has Hurd-specific patches.  Some have been forwarded
    upstream (and have been ignored).  [[Thomas_Schwinge|tschwinge]] is working
    on getting them integrated.

  * [\[meta-bug\] bootstrap bugs for
    \*-gnu\*](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824)

  * [build system: gcc\_cv\_libc\_provides\_ssp and
    NATIVE\_SYSTEM\_HEADER\_DIR](http://gcc.gnu.org/ml/gcc/2008-10/msg00130.html)

  * [-fstack-protector shouldn't use TLS in freestanding
    mode](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838)

      * See also commit bf1c0af128f33bd342636c4afeaa8f3a8a7cf8ca (reverted in
        commit a204f0622242865ffea889bd698bc7c7bd236bd1), commit
        05c1aa95e6c37b3b281d749c76c673392941a031.

  * Check before/after Joseph changes.  (Should be fine.)

  * 34618b3190c110b8926cc2b1db4b4eac95451995 »config-list.mk«

    What's this used for?  (Check ML.)  Ask to include i686-pc-gnu (once it is
    buildable out of the box)?  See also
    73905b5de0d9a086f22ded7638bb1c0ae1b91326.

  * Various testsuite bits should include `*-*-gnu*`, too.

  * [low] [[toolchain/cross-gnu]] toolchain bootstrap vs. `fenv.h` in libgcc's
    libbid:

        [...]/xgcc [...] -DIN_LIBGCC2 -fbuilding-libgcc [...] -Dinhibit_libc [...] -o bid_decimal_globals.o [...] -c [...]/libgcc/config/libbid/bid_decimal_globals.c
        [...]/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory
        compilation terminated.
        make[1]: *** [bid_decimal_globals.o] Error 1
        make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/i686-pc-gnu/libgcc'
        make: *** [all-target-libgcc] Error 2

    See threads at [[!message-id
    "AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]],
    [[!message-id "20110328225532.GE5293@synopsys.com"]], [[!message-id
    "4D52D522.1040804@gmail.com"]].  Can simply configure the first GCC with
    `--disable-decimal-float`.

    Alternatively, can we use `#ifndef inhibit_libc` for this (these?) file(s)?
    See `generic-nonstrack.c`, for example.  The latter (and also
    `generic-morestack-thread.c`) also has a nice explanation of `inhibit_libc`
    which could be centralized at one place, for example definition of
    `inhibit_libc`.

  * [low] [[toolchain/cross-gnu]]

        The directory that should contain system headers does not exist:
          /media/boole-data/thomas/tmp/gnu-0/sys_root/usr/include
        make[2]: *** [stmp-fixinc] Error 1
        make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/gcc'
        make[1]: *** [all-gcc] Error 2
        make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj'

    `mkdir` the directory for now, but what is really going on?  GCC has *use
    `/usr/include` patch*, but glibc still installs into `/include/`?

  * `__GLIBC__`

    IRC, freenode, #hurd, 2012-01-05:

        <civodul> on GNU/kFreeBSD, it's GCC that defines __GLIBC__, funny
        <youpi> ??
        <youpi> not from features.h ?
        <civodul> in gcc/config/kfreebsd-gnu.h
        <civodul> :-)
        <pinotree> correct, it's enabled in gcc's config
        <pinotree> i discovered that after banging my head on the wall trying
          to find out why some stuff wasn't compiling even after kfreebsd
          porting patches adding preprocessors checks for __GLIBC__

    GNU/kFreeBSD and GNU/kNetBSD: commit
    6396cc37141180db4d2c8f73cab4f5977d8a1e19 (2004-06-24, r83577),
    GNU/kOpenSolaris: commit 3bef40126fb1633018fce47828df0fa9f65f110c
    (2009-01-29, r143768).  See also GDB commits
    fda1b24c62843f81d31de2af57b1ed9c55f1e348 and
    1acb4f4ff73d20850a7524fc939d2651be75f47b, and binutils commits
    e3081899be7570eb90ccfd5d767950d3a62871ee,
    127c4d4a4fe65bd17ea64db1be7f3c93d393afcb,
    47dbf5b634b955c2db1221715d15751e1281546a, and
    ad2be7e8b846f4cd67fa1e032f98d5dc1cdb6b8d.

    IRC, freenode, #hurd, 2012-05-25:

        <gnu_srs> Hi, looks like __GLIBC__ is not defined by default for GNU?
        <gnu_srs> touch foo.h; cpp -dM foo.h|grep LIBC: empty
        <braunr> gnu_srs: well, this only tells your the compiler defaults
        <tschwinge> gnu_srs: See the email I just sent.

    [[!message-id "87396od3ej.fsf@schwinge.name"]]

        <braunr> __GLIBC__ would probably be introduced by a glibc header
        <gnu_srs> tschwinge: I saw your email. I wonder if features.h is
          included in the kFreeBSD build of webkit.
        <gnu_srs> It is defined in their build, but not in the Hurd build.
        <pinotree> gcc on kfreebsd unconditionally defines __GLIBC__
        <pinotree> (a bit stupid choice imho, but hardly something that could
          be changed now...)
        <braunr> :/
        <braunr> personally i don't consider this only "a bit" stupid, as
          kfreebsd is one of the various efforts pushing towards portability
        <braunr> and using such hacks actually hinders portability ...
        <pinotree> yeah don't tell me, i can remember at least half dozen of
          occasions when a code wouldn't have been compiling at all on other
          glibc platforms otherwise
        <pinotree> sure, i have nothing against kfreebsd's efforts, but making
          gcc define something which is proper of the libc used is stupid
        <braunr> it is
        <pinotree> i spotted changes like:
        <pinotree> -#ifdef __linux
        <pinotree> +#if defined(__linux__) || defined(__GLIBC__)
        <pinotree> and wondered why they wouldn't work at all for us... and
          then realized there were no #include in that file before that
          preprocessor check
        <tschwinge> This is even in upstream GCC gcc/config/kfreebsd-gnu.h:
        <tschwinge> #define GNU_USER_TARGET_OS_CPP_BUILTINS()               \
        <tschwinge>   do                                            \
        <tschwinge>     {                                           \
        <tschwinge>         builtin_define ("__FreeBSD_kernel__");  \
        <tschwinge>         builtin_define ("__GLIBC__");           \
        <tschwinge>         builtin_define_std ("unix");            \
        <tschwinge>         builtin_assert ("system=unix");         \
        <tschwinge>         builtin_assert ("system=posix");        \
        <tschwinge>     }                                           \
        <tschwinge>   while (0)
        <tschwinge> I might raise this upstream at some point.
        <pinotree> tschwinge: i could guess the change was proposed by the
          kfreebsd people, so asking them before at d-bsd@d.o would be a start
        <tschwinge> pinotree: Ack.
        <pinotree> especially that they would need to fix stuff afterwards
        <pinotree> imho we could propose them the change, and if they agree put
          that as local patch to debian's gcc4.6/.7 after wheezy, so there is
          plenty of time for them to fix stuff
        <pinotree> what should be done first is, however, find out why that
          define has been added to gcc

    [[!message-id "201211061305.02565.pino@debian.org"]].

  * [low] Does `-mcpu=native` etc. work?  (For example,
    2ae1f0cc764e998bfc684d662aba0497e8723e52.)

  * transactional memory, 4c0315d05fa0f707875686abc4f91f7a979a7c7b

      * `config/mmap.m4`

      * In `libitm/config/`, is the generic stuff (`tls.h`, etc.) enough for
        us?

      * f29a2041f32773464e226a83f41762c2e9cf658e
        (e53a96c2136f7cdff4699475fea41afeed9dece3)

    Testresults same as for GNU/Linux.

  * [high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a, `Check __GLIBC__ when
    using __SIGRTMIN`.  GCC PR52390.  Fixed by
    8d2259c83f94c082ad8a00b5d00bb639ce24efce.

  * 15ac1e637ad0cb92bf7629205c617ea847a4b810 `Build 64-bit libffi multilib for
    i?86-linux`.

  * `libstdc++`: uses `_GLIBCXX_HAVE_TLS`, but where is this defined?  Supposed
    to come from `config/tls.m4:GCC_CHECK_TLS`?

  * `libgcc/gthr-posix.h:__gthread_active_p` -- is this suitable for us?  This
    is used in libgcc for ObjC wrapper stuff and similar in libstdc++.
    C.f. [[!message-id "x57jobtqx89w.fsf@frobland.mtv.corp.google.com"]],
    [[!message-id "x57jd359fkx3.fsf@frobland.mtv.corp.google.com"]] as well as
    [[!debbug 629866]]/[[!message-id
    "20110609002620.GA16719@const.famille.thibault.fr"]].  commit
    026e608ecebcb2a6193971006a85276307d79b00.

  * 549e2197b118efb2d947aaa15d445b05c1b5ed62 `Import the asan runtime library
    into GCC tree`.  Linux-specific things:
    `ASAN_USE_ALIAS_ATTRIBUTE_FOR_INDEX`, `ASAN_LINUX`, `ASAN_POSIX`,
    `libsanitizer/asan/asan_linux.cc`,
    `libsanitizer/asan/asan_malloc_linux.cc`,
    `libsanitizer/asan/asan_posix.cc`,
    `libsanitizer/interception/interception.h`,
    `libsanitizer/interception/interception_linux.cc`,
    `libsanitizer/interception/interception_linux.h`,
    `libsanitizer/sanitizer_common/sanitizer_allocator.cc`,
    `libsanitizer/sanitizer_common/sanitizer_linux.cc`,
    `libsanitizer/sanitizer_common/sanitizer_posix.cc`,
    `libsanitizer/sanitizer_common/sanitizer_procmaps.h`,
    `libsanitizer/sanitizer_common/sanitizer_symbolizer_linux.cc`.
    4afab99bf0fe2d6905a9fa9d6ab886ca102312df `Enable libsanitizer just on x86
    linux for now`.  492e75a7336b4dbfe38207ea3abf8d5bd72376a9 `Move
    libsanitizer configure logic to subdirectory`.
    6aea389d84c2172668af5f108e2b17e131120d0b `Add STATIC_LIBASAN_LIBS for
    -static-libasan`.  Further commits later on.

      * 9cf754572854d9d9cd43c277eb7afb12e4911358 `Import tsan runtime from
        llvm`.  Linux-specific things: `libsanitizer/tsan/tsan_platform.h`,
        `libsanitizer/tsan/tsan_platform_linux.cc`,
        `libsanitizer/tsan/tsan_symbolize_addr2line_linux.cc`.
        a96132f29aa3dfe94141a87537f62ea73ce0fc19 `Set TSAN_SUPPORTED=yes for
        x86_64/i686-linux for 64-bit multilib`.  Further commits later on.


# Build

Here's a log of a GCC build run; this is from our [[Git repository's
dcdba5abca23716daa6aeb5c92f367e0978e4539 (2013-05-27;
0479dc77cf50ee78769b55563051cf72d39b3d60 (2013-05-27)), plus
`id:"87txlnlg0z.fsf@kepler.schwinge.homeip.net"`
sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE.

    $ export LC_ALL=C
    $ (cd ../master/ && contrib/gcc_update --touch)
    $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --enable-languages=all,ada 2>&1 | tee log_build
    [...]
    $ make 2>&1 | tee log_build_
    [...]

Different hosts may default to different shells and compiler versions; thus
harmonized.

We're stuck with GCC 4.6 until there are Debian *gnat-4.7* packages avaible.

This takes up around 3.5 GiB, and needs roughly 3.5 h on kepler.SCHWINGE and 15
h on coulomb.SCHWINGE.

<!--

    $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k check 2>&1 | tee log_test

-->


## Analysis

    $ toolchain/logs/process gcc build

  * [[`checking if gcc static flag -static
    works... no`|glibc_madvise_vs_static_linking]]

    Addressed in Debian glibc.

  * `host-linux.c` vs. `host-default.c`

  * *fixincludes* stuff

  * malloc?

        -cat ../../hurd/gcc/config/i386/pmm_malloc.h > mm_malloc.h
        +cat ../../hurd/gcc/config/i386/gmm_malloc.h > mm_malloc.h

    Comes from `gcc/config.gcc`: `i386/t-pmm_malloc` vs. `i386/t-gmm_malloc`
    for `i[34567]86-*-linux*` vs. `i[34567]86-*-*`.

  * *libgomp*

      * `libgomp/config/linux/`, `libgomp/config/linux/x86`

    `sed`ed away.

      * `-ftls-model=initial-exec -march=i486 -mtune=i686`

    `sed`ed away.

  * Missing `EOWNERDEAD`, `ENOTRECOVERABLE`.  What're they used for?

  * `RLIMIT_VMEM`.  Usage kosher?

  * `libtool: link: ar rc .libs/libstdc++.a [...]`

    Just different order of object files, or another problem?  TODO

  * `libobjc/encoding.c`:

         libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/encoding.c -c [...]
        +[...]/hurd/master/libobjc/encoding.c:128:1: warning: '_darwin_rs6000_special_round_type_align' defined but not used [-Wunused-function]

  * `libobjc/thr.c`: `gcc/gthr-posix.h`

         libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/thr.c -c [...]
        +In file included from [...]/hurd/master/libobjc/../libgcc/gthr.h:142:0,
        +                 from [...]/hurd/master/libobjc/thr.c:45:
        +../libgcc/gthr-default.h: In function '__gthread_objc_thread_set_priority':
        +../libgcc/gthr-default.h:388:41: warning: unused parameter 'priority' [-Wunused-parameter]

  * `/proc/self/*`

        -checking for /proc/self/exe... yes
        -checking for /proc/self/maps... yes
        +checking for /proc/self/exe... no
        +checking for /proc/self/maps... no

  * GCJ: `java-signal.h`, `java-signal-aux.h`

        -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal.h
        -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal-aux.h
        +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal.h
        +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal-aux.h

  * GCJ: `jni_md.h`

        -checking jni_md.h support... yes
        +checking jni_md.h support... configure: WARNING: no

  * *default library search path*

        -checking for the default library search path... /lib /usr/lib /lib/i386-linux-gnu /usr/lib/i386-linux-gnu /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib
        +checking for the default library search path... /lib /usr/lib

    [[binutils]] issue?  Should be aligned by Samuel's binutils patch.

  * `./classpath/[...]/*.properties`

    Just different order of files, or another problem?

  * `libjava/gnu/gcj/util/natGCInfo.cc`

         libtool: compile:  [...]/hurd/master.build/./gcc/xgcc [...] -c ../../../master/libjava/gnu/gcj/util/natGCInfo.cc [...]
        +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:440:1: warning: unused parameter 'name' [-Wunused-parameter]
        +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter]
        +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter]

  * `libgcj.la`

    Just different order of object files, or another problem?

    Is there a pattern that GNU/Hurd hands out the files alphabetically sorted
    where it wouldn't need to ([[!taglink open_issue_hurd]])?

  * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0`

    `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions`

  * `jar`

         make[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava'
        -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do
        +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do

    Probably because kepler.SCHWINGE has an OpenJDK `/usr/bin/jar`, and
    coulomb.SCHWINGE a GCJ one.

    There are other instances of this in the following.

  * `value-unwind.h`

        -DEFINES='' HEADERS='../../../master/libgcc/config/i386/value-unwind.h' \
        +DEFINES='' HEADERS='' \
                        ../../../master/libgcc/mkheader.sh > tmp-libgcc_tm.h

    Comes from `gcc/config.gcc`: for `i[34567]86-*-linux*`
    vs. `i[34567]86-*-*`, but apparently is important only for *x86_64* anyway.

  * `soft-fp` prototypes

         ../../../master/libgcc/soft-fp/eqtf2.c:34:9: warning: no previous prototype for '__eqtf2' [-Wmissing-prototypes]
        +../../../master/libgcc/soft-fp/eqtf2.c:50:1: warning: no previous prototype for '__netf2' [-Wmissing-prototypes]

         ../../../master/libgcc/soft-fp/getf2.c:34:9: warning: no previous prototype for '__getf2' [-Wmissing-prototypes]
        +../../../master/libgcc/soft-fp/getf2.c:50:1: warning: no previous prototype for '__gttf2' [-Wmissing-prototypes]

         ../../../master/libgcc/soft-fp/letf2.c:34:9: warning: no previous prototype for '__letf2' [-Wmissing-prototypes]
        +../../../master/libgcc/soft-fp/letf2.c:50:1: warning: no previous prototype for '__lttf2' [-Wmissing-prototypes]

  * `libatomic` on GNU/Linux compiles several more files than on GNU/Hurd.  Is
    that correct?  Probably futex support.

  * 2e2db3f92b534460c68c2f9ae64455884424beb6..3336556d2cb32f46322922a83015f760cfb79d8f

    Both GNU/Linux and GNU/Hurd:

        -checking assembler for rep and lock prefix... yes
        +checking assembler for rep and lock prefix... no

    TODO.


# Install

    $ make install 2>&1 | tee log_install
    [...]

This takes up around 1.1 GiB, and needs roughly 5 min on kepler.SCHWINGE and 37
min on coulomb.SCHWINGE.


## Analysis

    $ toolchain/logs/process gcc install

  * `libtool: finish`: `ldconfig` is not run for the Hurd.

    [[libtool]].

  * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0`

    `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` (as above)

  * `jar`: as above.


# Testsuite

<http://gcc.gnu.org/install/test.html>

Testing on GNU/Hurd is blocked on
[[fork_mach_port_mod_refs_ekern_urefs_owerflow]].

TODO.  On GNU/Hurd, it is advisable to reboot after having built and installed
GCC, before running the testsuite, as otherwise there seems to be a tendency
that the system crashes during the `gcc.c-torture/compile/limits-structnest.c`
tests, which are rather memory hungry, see [[!message-id
"87bol6aixd.fsf@schwinge.name"]].  Likewise, it also seems advisable to add
further reboots in between, that is, separate `make check`'s `check-host` into
several separate runs, and then one for `check-target` (see
`[build]/Makefile:do-check`, `[build]/gcc/Makefile:CHECK_TARGETS`), as
otherwise there seems to be a tendency for the system crashing sooner or later.
(Running `check-host` accumulates to something like 44 hours worth of
forking/execing of GCC and testcases.)  On GNU/Linux we run it in one go, so
that we'll catch any fundamental rearrangements of/additions to the testsuites.

kepler.SCHWINGE:

    $ make -k check 2>&1 | tee log_test
    [...]

coulomb.SCHWINGE:

    $ awk '/^maybe-check-target/ { next; }; /^maybe-check-[^:]*:./ { print; };' < Makefile
    maybe-check-fixincludes: check-fixincludes
    maybe-check-gcc: check-gcc
    maybe-check-intl: check-intl
    maybe-check-libbacktrace: check-libbacktrace
    maybe-check-libcpp: check-libcpp
    maybe-check-libdecnumber: check-libdecnumber
    maybe-check-libiberty: check-libiberty
    maybe-check-zlib: check-zlib
    maybe-check-gnattools: check-gnattools
    maybe-check-lto-plugin: check-lto-plugin
    $ grep ^CHECK_TARGETS < gcc/Makefile
    CHECK_TARGETS =  check-ada check-c check-c++ check-fortran check-java check-lto check-objc

    $ export LC_ALL=C

    [reboot]
    $ make -k check-fixincludes 2>&1 | tee log_test_1_check-fixincludes
    [...]
    $ make -k -C gcc check-ada 2>&1 | tee log_test_2_gcc_check-ada
    [...]
    [reboot]
    $ make -k -C gcc check-c 2>&1 | tee log_test_2_gcc_check-c
    [...]
    [reboot]
    $ make -k -C gcc check-c++ 2>&1 | tee log_test_2_gcc_check-c++
    [...]
    [reboot]
    $ make -k -C gcc check-fortran check-java check-lto check-objc 2>&1 | tee log_test_2_gcc_check-fortran,check-java,check-lto,check-objc
    [...]
    [reboot]
    $ make -k check-intl check-libbacktrace check-libcpp check-libdecnumber check-libiberty check-zlib check-gnattools check-lto-plugin 2>&1 | tee log_test_3
    [...]
    $ make -k check-target 2>&1 | tee log_test_4_check-target
    [...]

This needs roughly 7.25 h on kepler.SCHWINGE and 3.5 h (`check-fixincludes`,
`gcc/check-ada`) + 14 h (`gcc/check-c`) + 4.5 h (`gcc/check-c++`) + 6 h
(`gcc/check-fortran`, `gcc/check-java`, `gcc/check-lto`, `gcc/check-objc`) +
9.75 h (`check-intl`, [...], `check-lto-plugin`, `check-target`) = 37.75 h on
coulomb.SCHWINGE.


## Analysis

    $ toolchain/logs/process gcc test

  * PTYs

    Occasionally tests FAIL due to:

        spawn -open -1 failed, 1 5, The system has no more ptys.  Ask your system administrator to create more.

    TODO.

  * As of b401cb7ed15602d244a6807835b0b9d740a302a8 (2012-11-26;
    769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01)), all
    `gcc.dg/guality` and `g++.dg/guality` and a few more are no longer tested
    on coulomb.SCHWINGE and kepler.SCHWINGE.

  * As of b401cb7ed15602d244a6807835b0b9d740a302a8 (2012-11-26;
    769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01)), there are
    regressions (FAILs) in libgomp execution tests on coulomb.SCHWINGE.

  * 769bf18a20ee2540ca7601cdafabd62b18b9751b..be3860ba8df48cca3253da4f02fd2d42d856ce80

    On GNU/Hurd:

         Running [...]/hurd/master/gcc/testsuite/g++.dg/tls/tls.exp ...
        +FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local3g.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local4g.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local5.C -std=gnu++11 execution test
        +FAIL: g++.dg/tls/thread_local5g.C -std=gnu++11 execution test

    They used to PASS.

  * What is `gcc/testsuite/gcc.test-framework/test-framework.exp` and should we
    define `CHECK_TEST_FRAMEWORK` to run these tests?

  * TODO


## Enhancements


### `contrib/testsuite-management/`, `contrib/regression/`

  * 35a27ee8c4b349fea44fd1fadc9614ab3cc9d578 `Add an xfail manifest for
    x86_64-unknown-linux-gnu to trunk.`


### Parallel Testing

[[!message-id "20110331070322.GI11563@sunsite.ms.mff.cuni.cz"]].


### Distributed Testing


#### IRC, OFTC, #gcc, 2012-05-31

    <dnovillo> jsm28: in your mentor testing, you have the source and build
      tree available for make check?  or it's a pure installed-tree test?
    <jsm28> dnovillo: Source tree, install tree, no build tree.
    <dnovillo> jsm28: so, you run make check on top of the source tree or copy
      the */testsuite trees to a testing area?
    <jsm28> Create a site.exp and do runtest in a temporary directory.  runtest
      is pointed to the source tree to find sources.
    <jsm28> For cross testing for GNU/Linux targets, the temporary directory is
      mounted at the same path on host and target.
    <dnovillo> jsm28: thanks.  i guess i'll have to find the slice of the
      source tree i need to copy.
    <dnovillo> jsm28: for libstdc++ do you write a different site.exp? 
    <dnovillo> i noticed that it generates a different site,exp there.
    <jsm28> The site.exp is mostly the same for all testsuites (so includes
      settings that only some testsuites use).
    <dnovillo> ok, thanks.
    <dnovillo> and when you say "pointed to the source tree" you mean "set
      srcdir /path/to/top/of/gcc" ?
    <dnovillo> (in site.exp)
    <jsm28> The GDB testsuite requires that you run the GDB testsuite's
      configure script in the temporary directory where you will run runtest.
      I don't think any GCC testsuites we use have requirements like that.
    <jsm28> dnovillo: --srcdir option to runtest.
    <dnovillo> ah, yes.
    <jsm28> (and --tool, --target_board etc.)
    <dnovillo> right
    <dnovillo> since i'm distributing the tests. i want each node to only do a
      bunch of files.  this means that i either use 'tool.exp=file-pattern' or
      simply copy the subset of files i want tool.exp to find.
    <dnovillo> i chose the second approach, but that breaks in a handful of
      cases that need files from other sub-directories.
    <dnovillo> like g++.dg gcc.dg using stuff from c-c++-common.
    <dnovillo> for libstdc++, the possibilities for splitting are enormous as
      it has many directories.
    <dnovillo> but i'm not setting it right.  runtest runs without even trying
      to test anything.
    <dnovillo> i'm not having it pick up the right driver.
    <jsm28> Probably all .exp files should be copied to anywhere running
      testsuites, since some read .exp files from other directories.
    <dnovillo> jsm28: that could be it too.  it's irritating that libstdc++
      does not even error out.  runtest just does nothing and returns 0.

##### IRC, OFTC, #gcc, 2012-06-06

    <dnovillo> any libstdc++ maintainer around?
    <dnovillo> or, does anyone know when the testsuite/data files are copied
      into the running testsuite/ dir?
    <dnovillo> seems to be done in advance by make.

##### [[!message-id "4FC7791E.6040407@gmail.com"]]